Freebsd filesystem ( hard reboot )

[Peter Schuller]

> My understanding from the reading I have done is that in a situation like
> this where power outages are a danger (and presuably having the UPS signal
> the server to shut down gracefully is not practical), you need to make the
> file system as robust as possible in the first place, rather than rely on
> fsck -y after the event. Doesn't fsck -y rather sweep potential problems
> under the carpet?

fsck is not sweeping potential problems under the carpet, as long as nothing 
unexpected goes wrong (software bug, hardware problem).

The reason fsck works to begin with, is that it is designed to fix specific 
inconsistencies in the file system that are expected. The file system 
(takling about UFS here, and other non-journaled file systems that care about 
this stuff) is designed very carefully such that certain correctable 
inconsistencies happen, while preventing those that are not correctable.

That is, under fully expected circumstances, UFS is intended to require fsck 
on reboot. But it is NOT intended that fsck find unexpected inconcistencies 
and ask for operator intervention.

What happens in the event of write caching + power failure, software bug or 
hardware bugs, is that you end up with semi-random inconsistencies. fsck 
*may* be able to patch the situation enough for the file system to be usable, 
but fundamentally all bets are off.

> First step surely is to *disable* write caching if you have drives that
> are doing it?

For UFS/reiserfs/xfs/jfs/ext3fs/ext2fs, yes.

> Then consider mounting the file system synchronously. Mind you, I don't
> know what the scale of the performance loss would be, and whether anyone
> does this nowadays!

Synchronous mounting is not required for consistency (except perhaps for 
ext2fs; not sure). It is enough that the system does not break the file 
system's ability to guarantee ordering of certain critical operations, which 
is why write caching causes a problem (the drive re-orders writes for 
performance and you end up with B happening before A, but consistency 
depended on B happening AFTER A).

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller at infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey at scode.org
E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20071208/da353d20/attachment.pgp