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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
