[clug] Kernel without initramfs

[Michael Cohen]

Hi David,

We also use CF based cards with voyage linux. Now voyage does all the
hard work of separating rw and ro areas etc. However, we found that if
the power goes off while the system is in rw mode, there is a chance
that ext2 can become currupted. Now the funny thing about that is that
either the fs will fail to mount at boot time - which will stop your
embedded device dead in its tracks. Or, even more interestingly - the
kernel might just detect that the filesystem is corrupted at some
random time during operation, which will make it remount the fs ro.
This is particularly funny when servicing support calls like "I can
see the files, but I cant change them or add new files - whats going
on?"

EXT3 gives you the ability to recover from such problems. If you
modify your initrd to fsck every boot it will make sure that the
filesystem is ok even if the power went out during writing. The fsck
will be very quick usually because the journal will just be flushed.
We find that it more important for an embedded system to be robust
that efficient - after all I would rather wait a little at boot time
than have a brick on my hands on the other side of the continent.

As others mentioned wear leveling is done automatically in CF cards.
Although voyage makes most of the system ro most of the time (except
for those partitions we want to make rw). Separating rw and ro
filesystems can make sure that the system at least boots even if the
rw partition is totally hosed or worn out. The main aim is to get an
ssh connection at the very least, even if the main application cant
operate.

Michael.

On Thu, Mar 26, 2009 at 3:10 PM, David Cottrill
<cottrill.david at gmail.com> wrote:
> The ext3 was just to make sure it was all working - I'm planning on
> using ext2 for production.
>
> Because I'm planning on using this for a single application server
> with no chance of data recovery if there is a failure - journalling
> doesn't seem too useful for me. In my research it popped up that the
> journal is updated every minute by default - another nail in the
> coffin of ext3.
>
> I have considered XFS, but I'd have to look into the specifics of its
> journalling as well.
>
> Still can't get my non initrd kernel to boot but I've gotten
> sufficient speed just from better resarch into the boot process.
>
>
>
> On 3/26/09, Daniel Pittman <daniel at rimspace.net> wrote:
>> Robert Edwards <bob at cs.anu.edu.au> writes:
>>
>>> I notice in one of your earlier posts that you may be using ext3 on
>>> your CF device. May I suggest that it is a bad idea to use ext3 in
>>> particular and most other journalling FS's in general on a
>>> "flash"-based device?
>>
>> You can suggest that, but you would be wrong, since one of your
>> underlying assumptions is incorrect.
>>
>>> There are special FS's to use such as jffs, but I would recommend
>>> dividing up your file-system structure into read-only bits (eg. /usr)
>>> and writable parts.
>>
>> JFFS will not work without significant contortions on a CompactFlash
>> device, as it requires direct access to the underlying flash hardware.
>>
>> CF devices present as IDE, and have in-software wear levelling.
>>
>>> For the writable parts work out if you can afford to write to a
>>> RAM-base FS and then copy important data back to non-volatile
>>> storage. Logging etc., if possible, should be to an external logging
>>> server.
>>
>> That is generally good advice.
>>
>> Anyway, to the specifics of your suggestion: the reason that ext3 is no
>> more likely to cause a CF card trouble than any other filesystem is
>> simple, and that is that the CF card performs wear levelling internally.
>>
>> JFFS is designed for direct access to the flash hardware, in which there
>> is no hardware wear levelling, so it is essential to balance writes.
>>
>> Also, notably, most CF hardware is used with a FAT filesystem on it.
>> That has an even hotter write area than ext3, in that the FAT data is
>> much more fixed in place...
>>
>> Regards,
>>         Daniel
>> --
>> linux mailing list
>> linux at lists.samba.org
>> https://lists.samba.org/mailman/listinfo/linux
>>
> --
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux
>