[yocto] Question about file systems

[David Woodhouse]

On Tue, Mar 5 2013 at 08:20 -0800, Paul D. DeRocco wrote:
> So I guess the questions are these: Are ext2, ext3 and ext4 all equally
> likely to need to do an "fsck" after a disorderly shutdown? Do they
> typically take different amounts of time to do an "fsck"? Or is the
> journaling of ext3 and ext4 something that should be avoided on a flash
> drive at all costs, even though my app won't be doing much file access?

While ext2 will need a fsck after a disorderly shutdown, ext3 and ext4
should not. They are journalling file systems and an unclean shutdown
shouldn't affect them... *if* they can trust the underlying "disk".

However, you are using SSD-type storage, so that basically means you
*can't* trust the underlying disk. If you pull power from a device like
that when it isn't entirely quiescent, then you run the risk of the
*whole* device going wrong. It's got a kind of filesystem of its own
*internally*, which uses the flash and makes it *pretend* to have
atomically-overwritable 512-byte sectors like a disk. Oh, and it'll do
its own garbage collection in the background even when you're not
talking to it. So you can't *know* when it's quiescent.

Those internal file systems, or "flash translation layers", are almost
universally poorly implemented, and *will* lose data if you apply random
power failures to them. Asking about the file system that you use on
*top* of that "disk", be it fat/ext2/ext3/btrfs or whatever, is entirely
irrelevant. If you care about data integrity in an environment where
power is unsafe, then you really need to let the Linux system have
direct access to real flash chips and use a proper flash file system
like ubifs, *not* this misguided "pretend-to-be-spinning-rust" approach.
That was sensible in the DOS days where the only way we could provide
additional storage for the system was to implement an INT 13h DISK BIOS
handler, but it's completely unnecessary now.

If you try really hard and do extensive testing, and you pay over the
odds for your devices, you *might* manage to find one which (at least
for the batch you're testing until they change the innards again without
changing the model number) will pass your powerfail testing. Best of
luck with that. You'll need it.

If you're really stuck with this model of storage and can't fix it, then
I recommend you do some serious testing with automated power withdrawal
and see if you can live with the results. Forget the file system on top;
just test the device itself. On that note, I really ought to push some
*code* to http://git.infradead.org/mmctest.git to go with the
sternly-worded README.

With few writes, you're probably better off with ext3 rather than ext2.
It should avoid the need for a fsck. Until the device corrupts itself.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20130307/70892ede/attachment.bin>