Freebsd filesystem ( hard reboot )

Barnaby Scott bds at
Sat Dec 8 11:48:04 PST 2007

Peter Schuller wrote:
>> 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.

Exactly, which is why I thought that just bypassing all those 
interventions with -y was 'brushing under the carpet'. No?

> 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).

I realise it would normally be excessively cautious to go for 
synchronous mounting, but what about for environments where power supply 
is such a major problem?

More information about the freebsd-questions mailing list