Re: Have ext3 on SanDisk CF but can't disable write-back caching as kernel instructs

From: Dan Harkless (usenet_at_harkless.org)
Date: 07/18/03 

Date: 17 Jul 2003 20:52:37 -0700

steve@nospam.Watt.COM (Steve Watt) wrote in message news:<HI6w3H.9Hu@Watt.COM>:
> >My company is currently developing a Linux-based embedded device for
> >installation on airliners. The OS is based on SuSE 8.2 Pro's Minimum
> >System install.
>
> Yikes, a certification nightmare from the start...

Heh...
 
> >Our device may lose power at any time, but it's very important we
> >don't corrupt our data or our filesystem metadata, so our filesystems
> >(except our initrd-based root filesystem) are ext3, mounted
> >'data=journal'.
>
> As has been said many times through the thread, this is probably not
> a good way to do things, because of how the ext3 journal is laid
> out.

And as I've said a couple of times, unless the ext3 journal causes an
order of magnitude more writes to be done, or unless SanDisk's
wear-leveling algorithm is bogus, I don't see how it's significant for
Flash lifetime that we'll be using ext3 rather than ext2.

> You've said, later in the thread, that you have a power-off detector
> and a cap to provide some amount of run time after power failure.
>
> I'd solve this with two separate CF devices: One to boot & root from,
> that gets mounted read-only. The other one holds volatile data. Create
> a ramdisk the size of the volatile data CF, and use that exclusively
> until you get the power-off signal. Then dump the whole thing to
> the volatile data CF, while holding off writes as you had described
> elsewhere. You might even unmount the ramdisk (if possible) before
> dumping it to the flash so the image is clean.
>
> You need to be sure you have enough time on the backup cap for that
> write to complete, which shouldn't be all that much longer than
> the worst case for a whole boatload of dirty cache blocks.

No, we may accumulate many megabytes of data during a given uptime.
I'm sure we wouldn't always have time to dump that to Flash during the
200ms - 1 sec. we'll have between the low-voltage signal and capacitor
power drainage.

> Depending on how large your budget is (we *are* talking aircraft
> system prices, here), you could also go to some kind of battery-backed
> RAM for the read/write filesystem, as well. It's not that much more
> expensive than CF, and you get more flexibility.

Even if we're talking on the order of 256 MB worth?

Unfortunately it's a moot point, because the hardware has already been
designed, initial units built, and has gone through initial
qual-testing. Hardware was a done deal before I joined the company --
now I and the other software engineers need to determine how to make
it work and be robust and reliable. 

--
Dan Harkless
usenet@harkless.org
http://harkless.org/dan/

Relevant Pages