patrick42 asks:
"I am working on a project where I'll be replacing a DOS/Windows-based system with that of Linux or FreeBSD. The company for whom I'm working uses cheap PC's running some proprietary software on DOS/Windows to perform a certain task. The machines are deployed in environments where there are no keyboards or displays, and minimum-wage clerks are the people watching these machines. The company has decided to go with a free Unix system because they no longer wish to pay the licensing fees for Windows. The machines get unplugged all the time when they are moved or whatnot. They do not get a proper shutdown procedure ever, and it's not possible to change this due to the environments in which they are deployed. I've been told that they've never had a problem running DOS in terms of filesystem corruption. So I guess I'm looking for the safest filesystem possible that I can use with either FreeBSD or Linux. My head would be served on a platter if I picked something that sometimes requires user-intervention." Note that
Ask Slashdot covered a similar question back in 1999, the situations differed, but the need remains the same: can Linux work in environments where proper shutdowns are rare-to-non-existant?
"I have run many Linux machines, and I've experienced firsthand (only on occassion) where a machine did not get properly shutdown, and then on the next boot user-interaction was required to run fsck manually.
I really want to use either FreeBSD or Linux, but if there is any chance of this happening (hardware failures excluded) where someone needs to manually run fsck, I will not be able to use them.
I've been reading about the ext3 filesystem, and how corruption is quite rare, but it still seems possible. UFS claims to be quite stable as well, but fsck-less booting will not be available until FreeBSD 5.0 (from what I've read).
These machines aren't doing too much writing to the disk -- they are mostly just reading data, but that isn't to say that there will be no disk writes at all.
Can anyone offer some advice?"
Slashdot Mirror
Disable (or strictly limit) the write cache (-> Relevant documentation). Use a journaling filesystem. The result will be at least as good as with using the FAT-filesystem and DOS. The journaling filesystem means that the filesystem *structure* will always be consistent. Disabling the diskcache will reduce the chance of inconsistent *data* to DOS levels. But in the end, the application has to have precautions against inconsistent data, much like a journaling filesystem protects against inconsistent filesystem structure.
I've had to deal with a situation like this before - a hard drive in a laser printer, where there was no shutdown procedure, only an on/off switch. I used the "sync" option - e.g.
/dev/hda2 /usr
mount -t ext2 -o sync
This causes the filesystem to be mounted synchronous, so that there are no deferred writes and all disk writes are committed to the disk before the I/O call returns.
This is not 100% fool proof either, as it is still possible to power down the machine in the middle of a write, but it makes it much more difficult to screw up.
Darwin and Mac OS X runs fsck itself at boot and does not ask questions. It seems to handle it well. Darwin will run on x86. Mac OS X is proprietary, but does not have the steep licensing fees that windows does.
Soft Updates ensure that the filesystem is always in a consistent state. Updates are effectively not marked as complete until they have actually all gotten to disk. This ensures that after a re-boot, the system is consistent, maybe with the disk state as that of a some seconds earlier. The Soft Updates technique is also much faster than journalling, which is your other option (reiserfs, ext3fs etc in Linux).
I said above that fscking is practically eliminated - in fact a fsck task still needs to run to recover sectors that are 'dirty' but the system is stable without it - critically the system boots up without it, and in the background at some point when the system finds time to do so it recovers the sectors marked 'dirty'; the soft update people call this a "background fsck".
Note that this won't stop loss of data - but then nothing will stop loss of data. fsck certainly won't even if it is run properly, because that's not what it does. What it does do is ensure the filesystem metadata is always consistent (i.e. whether a file has been created/deleted, contents of directories etc).
More details on soft updates can be found in the OpenBSD FAQ and also in the FreeBSD handbookFreeBSD handbook.
If you want to get the same kind of disk flushing that you get with DOS, then you can only really do that with a single-tasking operating system (if that's not a contradiction in terms!) which can therefore ensure a minimum of delay between the application generating data and it being flushed to disk. Note this is never perfect, but can be close enough that you'd only notice one in a million power-offs.