Reply
Thread Tools
dacb's Avatar
Posts: 12 | Thanked: 1 time | Joined on Nov 2006 @ Earth, Sol, Milky Way, Universe
#1
A couple of thoughts/questions regarding the root filesystem:

1. Has anyone investigated using a/the compression optional mode of jffs2 for their root filesystem on the second partition of the mmc? I know of this patch: http://sourceware.org/ml/ecos-patche.../msg00039.html and IIRC there is a mount option based upon this idea to disable compression of jffs2 filesystems. The advantage of this would be a journaled, flash-safe filesystem without the uber performance hit that the compression has, particularly on our Nokia's.

2. Has anyone managed to get their ext2 on the second mmc partition to be fsck'ed on boot (when required)? I do not use bootmenu, opting rather to use flasher's --set-root-device option. I notice from dmesg that my ext2 filesystem is not checked at boot. Mounting an un-journaled filesystem without fscking it gives me the willies (http://www.urbandictionary.com/define.php?term=willies).

Just to head off any tangential threads: Please do not suggest using ext3 - ext3's journal(s) is written to the same sectors of the flash device (everytime it is updated) which is a big no-no for those of us who want to keep our MMC viable for the long haul. Think: flash on swap.

Last edited by dacb; 2006-11-27 at 22:05.
 

The Following User Says Thank You to dacb For This Useful Post:
gnuite's Avatar
Posts: 1,245 | Thanked: 421 times | Joined on Dec 2005
#2
Originally Posted by dacb
1. Has anyone investigated using a/the compression optional mode of jffs2 for their root filesystem on the second partition of the mmc?
I once tried extracting/decompressing the root partition data from Nokia's image file, then re-compiling the data (uncompressed where possible, which means only the root partition) into a new image. It wasn't straightforward - for one thing, the flasher has a limit on the size of the partition (about 100 MB? maybe 80... I don't remember), and the uncompressed version was more than 100 MB. I had to remove the video and MP3 files in order to get it under 100 MB.

I didn't notice any significant speedup, so I haven't continued that effort.

Originally Posted by dacb
2. Has anyone managed to get their ext2 on the second mmc partition to be fsck'ed on boot (when required)?
Is it set up to be checked in the /etc/fstab file? The last (sixth) field in each line determines when (if ever) a fsck is performed. "0" means never check. "1" is generally used only for the boot partition, and all other checked partitions are "2".

So make sure that, for your ext2 partition, it is "2" and not "0".

Even if that file is set up correctly, there still needs to be a boot script (in /etc/rc*) to actually perform the call to "fsck -A". Make sure that this is the case. If not, you'll have to write one (or steal one from another linux distro).
 
Posts: 286 | Thanked: 259 times | Joined on Jan 2006 @ Cambridge, England
#3
Originally Posted by dacb
A couple of thoughts/questions regarding the root filesystem:

1. Has anyone investigated using a/the compression optional mode of jffs2 for their root filesystem on the second partition of the mmc?
I think jffs2 on MMC is bad. Best to use ext2.

Originally Posted by dacb
Just to head off any tangential threads: Please do not suggest using ext3 - ext3's journal(s) is written to the same sectors of the flash device (everytime it is updated) which is a big no-no for those of us who want to keep our MMC viable for the long haul. Think: flash on swap.
I think the similiar thing applies to jffs2 on MMC, it is doubling up wear levelling and can shorten the life of the card. JFFS on a memory card is bad, because JFFS journalling adds to the number of write/erase cycles, which on a memory card would reduce its life. IMHO.

Rich
 
dacb's Avatar
Posts: 12 | Thanked: 1 time | Joined on Nov 2006 @ Earth, Sol, Milky Way, Universe
#4
Originally Posted by gnuite
I once tried extracting/decompressing the root partition data from Nokia's image file, then re-compiling the data (uncompressed where possible, which means only the root partition) into a new image. It wasn't straightforward - for one thing, the flasher has a limit on the size of the partition (about 100 MB? maybe 80... I don't remember), and the uncompressed version was more than 100 MB. I had to remove the video and MP3 files in order to get it under 100 MB.

I didn't notice any significant speedup, so I haven't continued that effort.
Good idea, bummer the performance was lacking. I'll take a peak at this and see what I can do, though at the moment my FC5 box refuses to loopback mount the jffs2 fs (init or root) in the Nokia 770 FIASCO - I wonder if this is particular to me or if others have had this problem with Fedora. This is particularly odd because it happily mounts my initfs for all of my OpenWRT images.

Originally Posted by gnuite
Is it set up to be checked in the /etc/fstab file? The last (sixth) field in each line determines when (if ever) a fsck is performed. "0" means never check. "1" is generally used only for the boot partition, and all other checked partitions are "2".
...
Even if that file is set up correctly, there still needs to be a boot script (in /etc/rc*) to actually perform the call to "fsck -A". Make sure that this is the case. If not, you'll have to write one (or steal one from another linux distro).
Interestingly enough, the /etc/fstab on partition 2 of my MMC is clobbered at each boot. I haven't yet had a chance to determine where in the initfs's boot scripts this is occuring (partially because of the aforementioned problem with Fedora loopback mounting the FIASCO initfs jffs2). Once identified, that would probably be the place to initiate the fsck. The problem is further complicated by the fact that the initfs, as far as I am aware (though I would love to be wrong), does not have e2fsck.
 
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#5
Forgot to press send yesterday, ingnore what have been said already.
Originally Posted by dacb
A couple of thoughts/questions regarding the root filesystem:

1. Has anyone investigated using a/the compression optional mode of jffs2 for their root filesystem on the second partition of the mmc? I know of this patch: http://sourceware.org/ml/ecos-patche.../msg00039.html and IIRC there is a mount option based upon this idea to disable compression of jffs2 filesystems. The advantage of this would be a journaled, flash-safe filesystem without the uber performance hit that the compression has, particularly on our Nokia's.
Yes, but current system does not fit well into 128MB without compression.

Originally Posted by dacb
2. Has anyone managed to get their ext2 on the second mmc partition to be fsck'ed on boot (when required)? I do not use bootmenu, opting rather to use flasher's --set-root-device option. I notice from dmesg that my ext2 filesystem is not checked at boot. Mounting an un-journaled filesystem without fscking it gives me the willies (http://www.urbandictionary.com/define.php?term=willies).
Automatic e2fsck -y might do what you don't want and you don't have keyboard for answering fsck questions while booting. What can be done is to use bootmenu and boot from flash and e2fsck it from system in flash. Consider using bootmenu :-)

Originally Posted by dacb
ext3's journal(s) is written to the same sectors of the flash device (everytime it is updated) which is a big no-no for those of us who want to keep our MMC viable for the long haul.
I guess this is a myth. MMC cards are mostly used with FAT filesystem which updates very same sectors (ie. FAT table) frequently. Most devices update it after writing each data sector (all PalmOS devices and windows probably too if you have se optimization for quick removal - default choice). If MMC cards wouldn't do its own wear leveling they would be dead pretty soon. There is layer of indirection inside card controller. Write to same sector doesn't go to same physical flash block. They are distributed across the card and have different size anyway. Also there is some hidden number of spare blocks if some go wrong.

Ext3 has journaling mode which gives you equivalent of ext2 (well, almost) but with automatic fsck on boot.

http://www.redhat.com/support/wpaper...ing.html#speed

This might be good to try if you want your data to be a bit safer and do not want to do fsck manually.
 
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#6
Originally Posted by dacb
Interestingly enough, the /etc/fstab on partition 2 of my MMC is clobbered at each boot. I haven't yet had a chance to determine where in the initfs's boot scripts this is occuring (partially because of the aforementioned problem with Fedora loopback mounting the FIASCO initfs jffs2). Once identified, that would probably be the place to initiate the fsck. The problem is further complicated by the fact that the initfs, as far as I am aware (though I would love to be wrong), does not have e2fsck.
In /etc/fstab there is no proper entry for root filesystem. Use 'df' and see that root is wrong. Also root is mounted rw from initfs so it is hard to fsck it. This can be changed in theory but IMHO is not worth it. I'd vote against automatic fsck on boot.
 
dacb's Avatar
Posts: 12 | Thanked: 1 time | Joined on Nov 2006 @ Earth, Sol, Milky Way, Universe
#7
Oh well....

'tune2fs -j' it is then; I may look into 'noatime' to keep the journal metadata updates to a minimum.

Thanks for the tips..
 
penguinbait's Avatar
Posts: 3,096 | Thanked: 1,525 times | Joined on Jan 2006 @ Michigan, USA
#8
Is there a way to have fsck -y on boot everytime so as to not have to boot into flash or alternate mmc to fsck and reboot? When its its clean it just exits anyway with nothing to fix.

This is not the optimal way I would assume. And I guess with now stable sd/mmc cards it may not be needed as much as before.
 
MoridinBG's Avatar
Posts: 70 | Thanked: 1 time | Joined on Sep 2007
#9
It seems that ext3 is really a killer for flash devices. ReiserFS turns out to be best in terms of flash wearing and handling small files. In the thread about booting from MMC I posted some links.
May be tomorrow will do some tests.
 
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#10
Well as mentioned above there are no e2fsutils in initfs and root fs is mounted by default read write. There are 2 solutions

1. initfs has to be modified to mount root partition read only and it should be remounted in rootfs rw after calling fsck (and rebooting in case of modification). This is how unix works on the desktop and anyone can look how it is done there and hack this themselves if they want it. It could even do without modifying initfs if it is remounted ro right before calling e2fsck.

2. e2fsutils need to be added to initfs (i.e. recompiled statically or with correct uclibc toolchain) and then e2fsck can be called before mounting root partition.

I plan to do 2. sometime in future but the priority is low since you can do 1. or boot to flash and call e2fsck by hand or use ext3. Also free space in initfs is low so it may not fit with other stuff. I guess e2fsutils are also in busybox so I'll do it once there is enough reasons to rebuild and replace busybox in initfs (one reason already is enabling support for long filenames in tar for easier backup in usb recovery mode).
__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 05:19.