You are not logged in.
I am editing rc.sysinit. But I really don't know at this point if it's the right line.
stat_busy "Mounting Local Filesystems"
#this is the original
#/bin/mount -n -o remount,rw / &> /dev/null
#first boot
#/bin/mount -n -o remount,rw,fcache_dev=3/5,fcache_prime=1 / &> /dev/null
#subsequent
/bin/mount -n -o remount,rw,fcache_dev=3/5,fcache_prime=0 / &> /dev/null
This it what I have done so far. As I ran the first prime, everything did boot slow like the gentoo howto said it would.
After KDE started up I stopped the prime and uncommented my subsequent line. Rebooted. It seems faster. I don't know how much differance it's making, or if it's even working.
I added &> /dev/null just because it was in the rest of the info I read
Offline
well checking dmesg I get this
fcache: found serial 17, expected 21.
fcache: reprime the cache!
ext3: failed to open fcache (err=-22)
Edit
I reprimed and dmesg gives
fcache: ios r/w 3209/277, hits 0, misses 0, overwrites 38
fcache: wrote 3209 extents, holding 169128 sectors of data
fcache: wrote header (extents=3209,serial=23)
fcache: header looks valid (extents=3209 extents, serial=23)
fcache: loaded 3209 extents
fcache: hda5 opened successfully (not priming)
I am going to reboot w/ the prime
After reboot I get this
fcache: header looks valid (extents=3209 extents, serial=23)
fcache: loaded 3209 extents
fcache: hda5 opened successfully (not priming)
well I did a boot chart of before and after and shaved 3 seconds off to get to console.
before
http://i4.photobucket.com/albums/y148/s … before.png
after
http://i4.photobucket.com/albums/y148/s … /after.png
Is something wrong w/ modules loading in the after?
anyways it was 3 seconds faster
I am still not sure if I am doing ths correctly
Offline
These are the steps I took:
1: Made a new 512M ext3 partition.
2: ls -l the new partition
[******@myhost ~]$ ls -l /dev/hdxy
brw-rw---- 1 root disk #, # 2006-07-04 13:39 /dev/hdxy
3:Edited /etc/rc.sysinit (look for line "stat_busy "Mounting Local Filesystems"")
Commented out the original "/bin/mount -n -o remount,rw / &> /dev/null"
4: Added
#this is the original
#/bin/mount -n -o remount,rw / &> /dev/null
#first boot
/bin/mount -n -o remount,rw,fcache_dev=#/#,fcache_prime=1 / &> /dev/null
#subsequent
#/bin/mount -n -o remount,rw,fcache_dev=#/#,fcache_prime=0 / &> /dev/null
Replace #/# with output from "ls-l /dev/hdxy
5: Rebooted
6: I let it cache untill KDE started then I ran
mount / -o remount,fcache_dev=#/#,fcache_prime=0
to stop the caching
7: Edited /etc/rc.sysinit again and comment out first boot and uncomment subsequent
#this is the original
#/bin/mount -n -o remount,rw / &> /dev/null
#first boot
#/bin/mount -n -o remount,rw,fcache_dev=#/#,fcache_prime=1 / &> /dev/null
#subsequent
/bin/mount -n -o remount,rw,fcache_dev=#/#,fcache_prime=0 / &> /dev/null
8:Rebooted and all seemed to work according to dmesg output
Offline
I am haing some problems with this,
I have get this error message at dmesg
ext3: failed to open fcache (err=-16)
EXT3-fs warning: mounting fs with errors, running e2fsck is recommended
EXT3 FS on hdb5, internal journal
I am using my file system on hdb5, and its numbers are 3 69
I have added this line
bin/mount -n -o remount,rw,fcache_dev=3/69,fcache_prime=1 / &> /dev/null
and I am using Kernel26-CK 1-2
Offline
Are you mounting the cache partition? It needs to be unmounted. Also are your sure your device number is correct? It may be 3/69 but unless you have 69 partitions on that drive, I don't think that's correct.
Offline
well it can be much more then 64, because 0 is hda
then 1-63 is all that connect to hdax
and then 64 and so on is hdb, I have fixed the problem here by unmount my swap and then tried to do this line, it say that every thing is ok, but kernel message say that something is currept and I should run ex2 check program, What can I do?
:?:
Offline
didn't know about the device thing. Thanks.
When I first tried doing this I was getting the error about the filesystem needing to be repaired because of bad superblock on the partition for the caching. I just removed the entry for the partition in fstab to prevent it from mounting.
I still don't know if I am doing this right myself. Everytime I make a change to my system, for example change my rc.conf, I check dmesg and fcache tells me to reprime. This is a pain in the *ss to do everytime. If someone could verify the steps I took, that would be great.
Offline
Easy way to find the device numbers, are simply to do
file /dev/hdxx
or
file /dev/sdxx
eg:
iphitus@sara:~$ file /dev/sda1
/dev/sda1: block special (8/1)
As for where to change rc.sysinit, the earliest you can do it is after
mount -n -t proc none /proc
[ "`grep sysfs /proc/filesystems`" ] && mount -n -t sysfs none /sys
and after that add
mount -n / -o remount,fcache_dev=#/#,fcache_prime=1
then reboot, that will do a prime run. after you have booted, end the prime run where you like, either after logging in, or in rc.local with,
mount -o remount,fcache_dev=#/#,fcache_prime=0
and then edit the line in your /etc/rc.sysinit to:
mount -n / -o remount,fcache_dev=#/#,fcache_prime=0
and it will use the primed partition next time you boot.
please note that the fcache version in beyond is slightly bugged, and if / is not mounted ro or umounted cleanly on boot, you need to do another prime run. this will be fixed in the next release
James
Offline
Is this really worth anything?
Seriously, if you want a good improvement in startup time, compile your own kernel.
Offline
Is this really worth anything?
Seriously, if you want a good improvement in startup time, compile your own kernel.
Read the first post. Yes it does.
And with a well configured initcpio, compiling your own kernel is somewhat questionable.
Offline
Hi,
> Read the first post. Yes it does.
Well, you talk about 6 seconds. That's indeed much. But look, if you are still over 25 seconds, and I guess my system is quite slower than yours (rather old, 1.6 Ghz), there is much more space left for improvements.
> And with a well configured initcpio, compiling your own kernel is
> somewhat questionable.
Well, recently I switched to the new kernel (-beyond) with initcpio because of that. but seriously: If you compile yourself and compile in everything you need, it boots _lots_ faster than the module + udev approach.
Next thing is, if you want to minimize boot time even more, you should consider using suspend2. I do, and that's the reason I don't care about boot time any more. Suspend2 is lots faster on boot, even faster on shutdown, and gives you back the state you can immediately continue to work with.
If you have this, you will scratch your head why you should go through the hassle with this cache partition thing anymore.
Regards,
Ford Prefect
p.s.: Trying out suspend2 is rather easy on arch now:
1. use kernel26beyond
2. add resume hook to your mkinitcpio
3. add resume2=swap:/dev/<swappartition> to your kernel parameters
4. install extra/hibernate-script
5. issue "hibernate" to suspend, or add it to /etc/acpi/handler.sh
Offline
> Read the first post. Yes it does.
Well, you talk about 6 seconds. That's indeed much. But look, if you are still over 25 seconds, and I guess my system is quite slower than yours (rather old, 1.6 Ghz), there is much more space left for improvements.
I never said there wasnt, since then I've made a few other changes to my system boot. In fcache itself there's room for improvement too as this is just the initial code, with no few improvements applied yet.
I dont know whether you've noticed, but there's an emerging trend, with many hdd vendors considering including a small flash partition in the drive. Seagate did this in a recent release of one of their momentus laptop hdds. fcache is a perfect way to use this flash storage effectively.
Well, recently I switched to the new kernel (-beyond) with initcpio because of that. but seriously: If you compile yourself and compile in everything you need, it boots _lots_ faster than the module + udev approach.
depends on where you time your boot from. your boot will be slower in the initial kernel stage as it loads all the drivers you compiled in, and quicker in the init boot stage.
A properly configured initcpio, and rc.conf, will boot in an equivalent time, give or take a second or two at most.
p.s.: Trying out suspend2 is rather easy on arch now:
1. use kernel26beyond
2. add resume hook to your mkinitcpio
3. add resume2=swap:/dev/<swappartition> to your kernel parameters
4. install extra/hibernate-script
5. issue "hibernate" to suspend, or add it to /etc/acpi/handler.sh
i know, i maintain half those packages
Suspend2 isnt a silver bullet, it doesnt solve everything, and doesnt work in every situation.
Offline
Hi,
I already thought you would know this, I wanted to include it from public.
I don't like this flash storage crap at all, but aside of that you are probably right.
Regards,
Ford Prefect
Offline