Freebsd filesystem ( hard reboot )
bds at waywood.co.uk
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