View previous topic :: View next topic |
Author |
Message |
Stephonovich n00b
Joined: 20 May 2004 Posts: 72 Location: United States
|
Posted: Sun Jul 31, 2005 1:50 am Post subject: |
|
|
Sheepdogj15 wrote: | has anyone heard about the Gigabyte i-RAM? i'm wondering if it will be supported by existing linux drivers (i don't see why not... just uses a SATA hdd interface), but if so, it could very well make these issues irrelevant. that is, assuming you have the money for it and 4 sticks of RAM, of course. |
Yeah, I was thinking about that awhile ago. Supposedly they'll get support for 4GB by the time they launch. I'd mount /usr (as much as possible, anyway) and /var in there. Ah... visions of nearly instantaneous emerge --sync... _________________ Who needs reincarnation when you've got parallel universes? |
|
Back to top |
|
|
Sheepdogj15 Guru
Joined: 07 Jan 2005 Posts: 430 Location: Backyard
|
Posted: Sun Jul 31, 2005 2:14 am Post subject: |
|
|
yeah, definitely. though i'm not so concerned about portage, as that's something i can run in the background while i'm doing other things. otherwise yeah... it will be very nice to get away from head latency and finally make full use of that 150MB/s pipe. _________________ Sheepdog
Why Risk It? | Samba Howto |
|
Back to top |
|
|
Beige Tangerine n00b
Joined: 13 Jun 2004 Posts: 7
|
Posted: Tue Aug 02, 2005 5:39 pm Post subject: unionfs / ldd script |
|
|
Based on some comments here, I've been working on some init scripts to mount only certain libraries in memory. I'm using a bash script (formerly a Perl script, but I wanted it to be able to run at boot time, even if /usr wasn't mounted) that runs ldd on any given files, follows symlinks, and automatically copies the appropriate libraries to ramdisks (one ramdisk for /usr/lib and one for /usr/bin). Then I use unionfs to mount each ramdisk together with its original directory.
I'm actually not terribly impressed with the load-time decrease on the one computer I've tried, but I think it's just because the hard drive is fast. (I can cat about 50MB worth of libraries to /dev/null in about a second and a half, if memory serves.) However, those of you who see 7-second improvements from your first boot of Firefox to the next are probably still very interested.
Then again, you might not even need to mount the libraries on a RAM disk. It might just be enough to read the libraries from disk (cat /usr/lib/whatever > /dev/null) so that they're stored in the cache. This may have much the same effect as starting Firefox (or whatever) once and then closing it. It would also avoid the dilemma of how to handle writes to /usr/lib (like when you update your system); my plan was to offer two runlevels: one that used ramdisks and had /usr/lib mounted read-only, and one that did not use ramdisks and had /usr/lib mounted read-write. If the performance gains are roughly equal, it would be much simpler not to have to worry about this.
Anyway, I'll post the script once I get home. It's not quite finished, especially since I'm not sure it's worth it for the computer I tried it on, but the part that lists all libraries required by the given programs seems to be working fairly well. |
|
Back to top |
|
|
Beige Tangerine n00b
Joined: 13 Jun 2004 Posts: 7
|
Posted: Wed Aug 03, 2005 12:56 pm Post subject: Re: unionfs / ldd script |
|
|
Here's the script. It has some comments, and I'll put some more below.
/etc/init.d/ramlibs Code: | #!/sbin/runscript
# TODO checkconfig section
# TODO die if a dir doesn't exist
# TODO note file that configuration comes from
function listLibs()
{
declare -a ALL_LIBS
# In theory, readlink might not be available because /usr/bin might not be mounted.
# My understanding is that we can assume that /bin is mounted (likewise for /lib, since it has libraries the bash requires).
# Actually, this happens after localmount, so I don't think that's a concern.
# Still, I found that busybox readlink is faster than standard readlink, so I'm not going to mess with it for now.
# We need busybox for this, but it appears to be pulled in by 'emerge system," so we should be able to count on it.
# Interestingly, this even beats the normal readlink -f for speed.
function readlink()
{
busybox readlink -f $1
}
# Normal readlink version.
#function readlink()
#{
# `which readlink` -f $1
#}
function appendToAllLibs()
{
ALL_LIBS[${#ALL_LIBS[*]}]=$1
echo $1
}
function isInAllLibs()
{
for (( J = 0 ; J < ${#ALL_LIBS[*]} ; J++ )); do
if [[ ${ALL_LIBS[$J]} == $1 ]]; then
true; return
fi
done
false; return
}
while [[ $# -ne 0 ]]; do
appendToAllLibs `readlink $1`
shift
done
# Looking at the output, I get the impression that recursion is not actually be necessary.
# I'm not sure, but the script is slower if we leave it in.
# Use the commented-out for() instead of the ORIG_COUNT and other for() to "reactivate" it.
#for (( I = 0 ; I < ${#ALL_LIBS[*]} ; I++ )); do
ORIG_COUNT=${#ALL_LIBS[*]}
for (( I = 0 ; I < $ORIG_COUNT ; I++ )); do
CURRENT_LIB=${ALL_LIBS[$I]}
# The commented-out version spawns a subshell, which means that ALL_LIBS is local to it. Not good.
# ldd 2> /dev/null $CURRENT_LIB | sed -e 's/^\t//' | sed -e 's/^.* => //' | sed -e 's/ (0x.*)$//' | grep -v '^$' | grep -v '^statically linked$' | while read LIB; do
for LIB in `ldd 2> /dev/null $CURRENT_LIB | sed -e 's/^\t//' | sed -e 's/^.* => //' | sed -e 's/ (0x.*)$//' | grep -v '^$' | grep -v '^statically linked$'`; do
LIB=`readlink $LIB`
if ! isInAllLibs $LIB; then
appendToAllLibs $LIB
fi
done
done
}
function start()
{
LIBS=(/usr/lib/MozillaFirefox/firefox-bin /usr/lib/MozillaThunderbird/thunderbird-bin /usr/bin/AbiWord-2.2 /usr/bin/gnumeric /usr/bin/gimp-2.2 /usr/bin/leafpad /usr/bin/xpdf /usr/bin/rhythmbox /usr/bin/gmplayer /usr/bin/oggenc /usr/bin/cdparanoia /usr/bin/eject /usr/bin/easytag)
ebegin "Copying libraries from ${#LIBS[@]} programs to RAM"
# TODO remove to config file
MERGEDIRS=(/usr/bin /usr/lib64)
RAMDIRS=(/usr/bin_ram /usr/lib64_ram)
HDDIRS=(/usr/bin_hd /usr/lib64_hd)
for (( I = 0 ; I < ${#MERGEDIRS[@]} ; I++ )); do
MERGEDIR=${MERGEDIRS[$I]}
RAMDIR=${RAMDIRS[$I]}
HDDIR=${HDDIRS[$I]}
mount tmpfs $RAMDIR -t tmpfs
mount -t unionfs -o dirs="$RAMDIR=ro:$HDDIR=ro" none $MERGEDIR
done
if [[ ${#MERGEDIRS[@]} -ne ${#RAMDIRS[@]} || ${#MERGEDIRS[@]} -ne ${#HDDIRS[@]} || ${#RAMDIRS[@]} -ne ${#HDDIRS[@]} ]]; then
# TODO say what file to edit
eerror "Arrays MERGEDIRS, RAMDIRS, and HDDIRS must be of equal length."
fi
einfo "Test variable: $TESTING"
# TODO Note that spaces will probably break this.
listLibs ${LIBS[@]} | while read LIB; do
for (( I = 0 ; I < ${#MERGEDIRS[@]} ; I++ )); do
MERGEDIR=${MERGEDIRS[$I]}
RAMDIR=${RAMDIRS[$I]}
HDDIR=${HDDIRS[$I]}
if echo $LIB | grep "^$MERGEDIR" > /dev/null; then
LIBDIR=`dirname $LIB`
SHORTLIBDIR=`echo $LIBDIR | sed -e "s#^$MERGEDIR##"`
mkdir -p $RAMDIR$SHORTLIBDIR
SHORTLIB=`echo $LIB | sed -e "s#^$MERGEDIR##"`
cp $HDDIR$SHORTLIB $RAMDIR$SHORTLIBDIR
fi
done
done
}
function depend()
{
before *
need localmount
}
function stop()
{
# TODO remove
MERGEDIRS=(/usr/bin /usr/lib64)
RAMDIRS=(/usr/bin_ram /usr/lib64_ram)
HDDIRS=(/usr/bin_hd /usr/lib64_hd)
estart "Unmounting library RAM drives"
for (( I = 0 ; I < ${#MERGEDIRS[@]} ; I++ )); do
MERGEDIR=${MERGEDIRS[$I]}
RAMDIR=${RAMDIRS[$I]}
HDDIR=${HDDIRS[$I]}
umount $MERGEDIR
umount $RAMDIR
done
} |
In theory, LIBS, MERGEDIRS, RAMDIRS, and HDDIRS would eventually be moved to /etc/conf.d/ramlibs.
You need busybox installed. I think it's part of system now, so you should probably have it. If not, emerge it.
You also need unionfs, which you can get from portage.
There's a circular dependencies complaint at shutdown.
Here's the most important function:
listLibs file1 [file2 [file3 ...]]
Print a list of libraries (with duplicates removed and symlinks fully resolved) required by the given file(s). (This includes the file itself. Note that this won't work for scripts, e.g., rip. That's why my LIBS contains '/usr/bin/oggenc /usr/bin/cdparanoia /usr/bin/eject')
Note that the current version of the script is for AMD64 (hence lib64 instead of lib).
As currently written, the script expects the "real" /usr/lib64 to be mounted at /usr/lib64_hd. (You would probably have to move the directories at the console and edit /etc/fstab.) It also expects /usr/lib64 and /usr/lib64_ram directories to exist (and, presumably, to be empty). (/usr/bin is similar, with /usr/bin_hd and /usr/bin_ram.) The script scans the files in LIBS, and any files it lists from /usr/lib64 and /usr/bin are copied from the appropriate _hd directory to the appropriate _ram directory. Then each _ram/_hd pair of directories is mounted together with unionfs, e.g., /usr/lib64 is /usr/lib64_ram and /usr/lib64_hd. This way, the system looks on the ramdrive first for any libraries.
Currently /usr/bin and /usr/lib64 are mounted read-only. Mounting the RAM drive read/write is a bad move because any changes you make to it (probably with portage) will be wiped on reboot. (It might also fill up quickly if you emerged something large, like Eclipse.) You could write a script to copy /usr/lib64_ram to /usr/lib64_hd at shutdown time, but if the power goes out or the computer locks up, you might have problems. Mounting the hard drive read/write is also bad, because any changes made by portage, etc. to a library that is also present on the RAM drive will not show up until you reboot, which is odd behavior.
My plan had been to eventually create another init script that just mounted a read/write copy of /usr/lib64_hd at /usr/lib64 (and similarly, /usr/bin_hd at /usr/bin). I would put it in a new runlevel, and then I could choose at bootup whether I wanted the fast, unmodifiable libs or the slower, writeable libs. In theory, you could even switch runlevels once you had started, though it would involve closing down X and other programs, since they would be using the libraries.
Oh, and a warning: Don't try this with /bin or /lib. The system needs to be able to run bash at startup. Bash is located in /bin, and it requires libraries in /lib. I'd go so far as to say that there is almost certainly a way to get around this, but I didn't think it would be worth it, as most of the files in those directories are small, anyway. Your situation may vary.
Let me know if you have any questions. I'm sure I missed some important things. Finally, let me reiterate that this is NOT a finished script. If you want to use it, you'll have to play around with it, and it's easy to make your system unbootable along the way. |
|
Back to top |
|
|
apberzerk Apprentice
Joined: 11 Jan 2004 Posts: 278 Location: kansas...
|
Posted: Thu Aug 04, 2005 5:39 am Post subject: |
|
|
I've seen several posts concerning this issue: what happens when you emerge something and write to the ramdisk? I am uncomfortable with the idea of just updating the HD with the contents of the ramdisk on shutdown. If the system fails and for some reason does not shut down properly, you lose the results of your emerges.
It seems to me that the following would be really nice to have (and I don't know how much of it already exists):
When something writes to /usr/lib or /lib or whatever you have mounted in ramdisk, it writes to the hard drive as well as the ramdisk. When something reads from any of these locations, it reads from ramdisk. How would such a thing be implemented? |
|
Back to top |
|
|
Beige Tangerine n00b
Joined: 13 Jun 2004 Posts: 7
|
Posted: Thu Aug 04, 2005 2:34 pm Post subject: |
|
|
apberzerk wrote: | I've seen several posts concerning this issue: what happens when you emerge something and write to the ramdisk? I am uncomfortable with the idea of just updating the HD with the contents of the ramdisk on shutdown. If the system fails and for some reason does not shut down properly, you lose the results of your emerges.
It seems to me that the following would be really nice to have (and I don't know how much of it already exists):
When something writes to /usr/lib or /lib or whatever you have mounted in ramdisk, it writes to the hard drive as well as the ramdisk. When something reads from any of these locations, it reads from ramdisk. How would such a thing be implemented? | As I understand it, this isn't possible with unionfs, though I may be overlooking something. See "Writing to Union" at the unionfs website: Quote: | ...all changes are stored in leftmost branch. | In other words, just the ramdisk, or just the hard drive, but not both.
This is why I had planned to mount the ramdisk/hard drive union read-only and offer a separate, hard-drive-only mode for running portage, etc. (Well, I was also worried that the ramdisk would fill up if I emerged something like Eclipse:) Code: | cpovirk@eleventy ~ $ du -sk /usr/lib/eclipse-3/
102115 /usr/lib/eclipse-3/ | Anyone have any other ideas? |
|
Back to top |
|
|
Sheepdogj15 Guru
Joined: 07 Jan 2005 Posts: 430 Location: Backyard
|
Posted: Fri Aug 05, 2005 1:30 am Post subject: |
|
|
i haven't messed with Ramdisk, but i have a few things set up in a tmpfs "partition." what i do is have it untar my stuff into the tmpfs on startup and set my mount points. on shutdown, it retars all the contents (in case something has changed, like i did an emerge). i've also made a backup tarball after a major emerge in case my computer dies before it can have a successful shutdown. i figure as long as i remember to do the backups or at least never have nasty system crashes, i'll be fine. _________________ Sheepdog
Why Risk It? | Samba Howto |
|
Back to top |
|
|
apberzerk Apprentice
Joined: 11 Jan 2004 Posts: 278 Location: kansas...
|
Posted: Fri Aug 05, 2005 6:30 pm Post subject: |
|
|
Sheepdogj15 wrote: | i figure as long as i remember to do the backups or at least never have nasty system crashes, i'll be fine. |
I have one of those every week I think...
- Phil |
|
Back to top |
|
|
SaBer n00b
Joined: 11 Aug 2005 Posts: 16
|
Posted: Fri Aug 12, 2005 8:05 am Post subject: |
|
|
apberzerk wrote: | I've seen several posts concerning this issue: what happens when you emerge something and write to the ramdisk? I am uncomfortable with the idea of just updating the HD with the contents of the ramdisk on shutdown. If the system fails and for some reason does not shut down properly, you lose the results of your emerges.
It seems to me that the following would be really nice to have (and I don't know how much of it already exists):
When something writes to /usr/lib or /lib or whatever you have mounted in ramdisk, it writes to the hard drive as well as the ramdisk. When something reads from any of these locations, it reads from ramdisk. How would such a thing be implemented? |
Could one perhaps create a raid1-array with a partition and a ramdisk? _________________ There are 10 kinds of people in this world: Those who understand binary, and those who don't. |
|
Back to top |
|
|
R4miu5 Apprentice
Joined: 01 Feb 2005 Posts: 263 Location: Mödling / Austria
|
Posted: Thu Aug 18, 2005 2:22 pm Post subject: |
|
|
as far as i know the section
Code: | echo /sbin/update-balls >> /etc/conf.d/local.stop
chmod +x /sbin/update-balls
cat /sbin/update-balls |
will run the creation of the tarballs at every shutdown? |
|
Back to top |
|
|
blue666man n00b
Joined: 01 Mar 2005 Posts: 15
|
Posted: Fri Aug 19, 2005 10:18 am Post subject: |
|
|
I think some readers on this forum might find this interesting:
It's a 66MHz 64-bit PCI-X (NOT pci express) card. Features:
Capacity: 2GB, 4GB, 8GB, 16GB
Battery backup: Multiple Redundant, Rechargeable On-board Batteries
Semaphore DMA Initiator for maximizing read and write transfers
Supports Interrupts
Error Detection and Correction
Burst Mode Transfer Rate: 533 MB/s peak
Some ppl were looking into the Gigabyte ramdisk, but I don't see the real benefit since I/O on SATA-I is capped at 150MB/s. The other, bigger, problem with solid state disks which use IDE or SATA is that you're not getting the 'R' benefit of RAM. All OS's handle IDE, SCSI, and SATA with sectors on a disk in mind. Not to mention, all your fav. file systems: reiser, xfs, jfs, ext*, etc. are also built around the fact that fragmentation slows access because a DISK has to spin and a r/w head has to move. There's no such thing on CMOS'es. But gigabyte and company will never make a ramdisk that ISN'T IDE or SATA b/c M$ Winblows can't handle what linux can: ramfs.
Anyway, if someone has a xeon MB with a PCI-X slot, I'd take a look into this card. Imagine a 16GB big filesystem where every I/O's seektime is in the hundreds of nanoseconds, not singles of milliseconds (about 20 to 25 times faster)! And a throughput of 533 MB/s! Not to mention the joy of seeing your PC boot as quickly as a palm pilot, but I digress. |
|
Back to top |
|
|
Jonasx Tux's lil' helper
Joined: 26 Mar 2004 Posts: 118
|
Posted: Wed Sep 14, 2005 7:21 pm Post subject: |
|
|
If your having trouble getting the linuxrc to execute, try taking the first row of hashes out, seems I needed the interpreter as the first line to make it go through...
also, you may need to specify the fs type with the -t option in linuxrc file when you mount. This is the only way I could get a reiser4 part to mount here.
I've almost gotten a native 64bit system w/ 2 gigs of ram like I want it, I'll post some of my experiences and hang ups shorty so it may help some others out
Edit:
And thaks for the great how to _________________ "If you understand what you're doing, you're not learning anything." - Anon |
|
Back to top |
|
|
gingekerr n00b
Joined: 12 Aug 2005 Posts: 4 Location: Reigate/Cambridge, UK
|
Posted: Mon Sep 19, 2005 1:59 pm Post subject: |
|
|
Is it not possible just to take advantage of the linux disk caching by doing a cat /lib/* > /dev/null ? (or something slightly smarter with find or for... test -f &&
This has no fixed memory usage, no problems with improper shutdowns and is all-in-all simpler. Of course, it doesn't have the security advantages of RAM root partitions. |
|
Back to top |
|
|
Enlight Advocate
Joined: 28 Oct 2004 Posts: 3519 Location: Alsace (France)
|
Posted: Tue Sep 20, 2005 3:36 pm Post subject: |
|
|
gingekerr wrote: | Is it not possible just to take advantage of the linux disk caching by doing a cat /lib/* > /dev/null ? (or something slightly smarter with find or for... test -f &&
This has no fixed memory usage, no problems with improper shutdowns and is all-in-all simpler. Of course, it doesn't have the security advantages of RAM root partitions. |
readahead <file> if I remember correctly. |
|
Back to top |
|
|
frawd n00b
Joined: 21 Sep 2005 Posts: 5
|
Posted: Sun Oct 02, 2005 9:03 pm Post subject: |
|
|
Anyone think that using this and prelinking binaries could give any kind of problems?
http://www.gentoo.org/doc/en/prelink-howto.xml
Would it speed up loading times more or is it just not worth it?
Thanx |
|
Back to top |
|
|
Enlight Advocate
Joined: 28 Oct 2004 Posts: 3519 Location: Alsace (France)
|
Posted: Mon Oct 03, 2005 2:45 pm Post subject: |
|
|
If your tarballs are correctly updated, I can't see how this could cause troubles. And I would say that yes It can speed a bit things but you won't fell it as much as when your libs and progs are on the disk. (adn I personnaly saw very few difference whan it is on HD) |
|
Back to top |
|
|
adsmith Veteran
Joined: 26 Sep 2004 Posts: 1386 Location: NC, USA
|
Posted: Mon Oct 03, 2005 3:11 pm Post subject: |
|
|
gingekerr wrote: | Is it not possible just to take advantage of the linux disk caching by doing a cat /lib/* > /dev/null ? (or something slightly smarter with find or for... test -f &&
This has no fixed memory usage, no problems with improper shutdowns and is all-in-all simpler. Of course, it doesn't have the security advantages of RAM root partitions. |
This sounds like a much better idea.
In particular, how about this:
Code: |
abe@tock ~ $ eix readahead
* sys-apps/readahead-list
Available versions: ~0.20050320.2320 ~0.20050323.0658 ~0.20050328.0142 ~0.20050425.1452 0.20050517.0220
Installed: none
Homepage: http://tirpitz.iat.sfu.ca/
Description: Perform readahead(2) to pre-cache files.
|
Haven't tried it yet, but it seems liks this sort of option is much better. Let the kernel itself deal with moving things from page cache -- it's very good at it, afterall. All you need to do is let it know what you want pre-lopaded. This seems safer and less hackish than an involved tar/mount script. It's also probably faster, though I have no proof yet. |
|
Back to top |
|
|
adsmith Veteran
Joined: 26 Sep 2004 Posts: 1386 Location: NC, USA
|
|
Back to top |
|
|
Frunktz n00b
Joined: 25 Oct 2005 Posts: 2
|
Posted: Tue Oct 25, 2005 2:11 pm Post subject: |
|
|
Well, in this way I lost some minute for extract tarball and copy the context on the RAM. Am I wrong?
Thanks a lot.
Ps:- Copy the /usr in RAM took me about 15-20 sec... |
|
Back to top |
|
|
Adwin Tux's lil' helper
Joined: 13 Mar 2005 Posts: 128 Location: Poland
|
Posted: Sun Oct 30, 2005 1:37 am Post subject: |
|
|
The most important thing is commiting changes both on the ramdisk files AND syncing them in real time to HDD files.
Any idea how to do this, except for rsync ? |
|
Back to top |
|
|
SaBer n00b
Joined: 11 Aug 2005 Posts: 16
|
Posted: Tue Nov 01, 2005 9:57 am Post subject: |
|
|
Adwin wrote: | The most important thing is commiting changes both on the ramdisk files AND syncing them in real time to HDD files.
Any idea how to do this, except for rsync ? |
I'm still thinking raid1...
Check this out: http://lkml.org/lkml/2005/9/4/223 _________________ There are 10 kinds of people in this world: Those who understand binary, and those who don't. |
|
Back to top |
|
|
TenPin Guru
Joined: 26 Aug 2002 Posts: 500 Location: Kansas City
|
Posted: Sat Nov 05, 2005 9:19 pm Post subject: |
|
|
So this essnetially moves the hard disk load times from when you run an application to boot time and ensures that stuff is permanently cached. It also adds time cosuming retarballing for when you emerge something into the tmpfs or shut down.
Another way of doing this could be to just cat /usr/bin/blah > /dev/null all the libraries and binarys that you want to be cached on boot. Then they will be cached and if you have lots of ram will stay cached.
I find that with 512Mb that the kernel caching works just fine and loading openoffice or firefox for the second time is instantaneous. Sure I lose the cache if I need to use that memory but thats better than having the memory locked into a tmpfs and having to use swap.
It seems to be more trouble than its worth to do this, especially on a laptop which is being shutdown frequently. _________________ For since in the wisdom of God the world by its wisdom did not know God, God was pleased to save those who believe by the foolishness of preaching. |
|
Back to top |
|
|
brazzmonkey Guru
Joined: 16 Jan 2005 Posts: 372 Location: between keyboard and chair
|
Posted: Wed Feb 15, 2006 8:49 am Post subject: |
|
|
adsmith wrote: | how about this:
Code: |
abe@tock ~ $ eix readahead
* sys-apps/readahead-list
Available versions: ~0.20050320.2320 ~0.20050323.0658 ~0.20050328.0142 ~0.20050425.1452 0.20050517.0220
Installed: none
Homepage: http://tirpitz.iat.sfu.ca/
Description: Perform readahead(2) to pre-cache files.
|
Haven't tried it yet, but it seems liks this sort of option is much better. Let the kernel itself deal with moving things from page cache -- it's very good at it, afterall. All you need to do is let it know what you want pre-lopaded. This seems safer and less hackish than an involved tar/mount script. It's also probably faster, though I have no proof yet. |
how do you get it configured ? i couldn't find relevant documentation on this one. |
|
Back to top |
|
|
adsmith Veteran
Joined: 26 Sep 2004 Posts: 1386 Location: NC, USA
|
Posted: Wed Feb 15, 2006 1:24 pm Post subject: |
|
|
You edit /etc/conf.d/preload, something like this:
Code: |
## verbosity. 0-9, Default is 4.
PRELOAD_VERBOSITY="3"
## this is where preload will store its pid file
#PRELOAD_PIDFILE="/var/run/preload.pid"
## can't get this to work.. :(
## set this for niceness. Default is 15
PRELOAD_NICE="15"
## log file
PRELOAD_LOGFILE="/tmp/log/preload.log"
|
Then you need an init file, something like this:
Code: |
#!/sbin/runscript
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
opts="${opts} reload dump"
#depend() {
# after xdm
#}
dump() {
ebegin "Dumping config and state for preload"
killall -SIGUSR1 /usr/sbin/preload
killall -SIGUSR2 /usr/sbin/preload
eend $?
}
reload() {
ebegin "Reloading config for preload"
killall -SIGHUP /usr/sbin/preload
eend $?
}
start() {
ebegin "Starting preload"
start-stop-daemon --start --quiet --exec /usr/sbin/preload -- \
--logfile ${PRELOAD_LOGFILE} -V ${PRELOAD_VERBOSITY} -n ${PRELOAD_NICE}
eend $?
}
stop() {
ebegin "Stopping preload"
start-stop-daemon --stop --quiet --exec /usr/sbin/preload
eend $?
}
|
|
|
Back to top |
|
|
brazzmonkey Guru
Joined: 16 Jan 2005 Posts: 372 Location: between keyboard and chair
|
Posted: Wed Feb 15, 2006 1:37 pm Post subject: |
|
|
ok, thanks for that.
i suppose i also have to edit a list so that it knows what has to be preloaded. am i right ? if so, where's this list ? |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|