Date: Sat, 08 Dec 2007 19:47:55 +0000 From: Barnaby Scott <bds@waywood.co.uk> To: Peter Schuller <peter.schuller@infidyne.com> Cc: Randy Ramsdell <rramsdell@livedatagroup.com>, freebsd-questions@freebsd.org Subject: Re: Freebsd filesystem ( hard reboot ) Message-ID: <475AF4EB.4090208@waywood.co.uk> In-Reply-To: <200712080736.50433.peter.schuller@infidyne.com> References: <4758180C.4060208@livedatagroup.com> <4758266E.6040704@livedatagroup.com> <2784.85.211.82.64.1196976328.squirrel@www.gradwell.com> <200712080736.50433.peter.schuller@infidyne.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?475AF4EB.4090208>