Freebsd filesystem ( hard reboot )
peter.schuller at infidyne.com
Fri Dec 7 22:35:04 PST 2007
> 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
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20071208/da353d20/attachment.pgp
More information about the freebsd-questions