Date: Sat, 8 Dec 2007 07:36:49 +0100 From: Peter Schuller <peter.schuller@infidyne.com> To: freebsd-questions@freebsd.org Cc: Barnaby Scott <bds@waywood.co.uk>, Randy Ramsdell <rramsdell@livedatagroup.com> Subject: Re: Freebsd filesystem ( hard reboot ) Message-ID: <200712080736.50433.peter.schuller@infidyne.com> In-Reply-To: <2784.85.211.82.64.1196976328.squirrel@www.gradwell.com> References: <4758180C.4060208@livedatagroup.com> <4758266E.6040704@livedatagroup.com> <2784.85.211.82.64.1196976328.squirrel@www.gradwell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1219279.2iA4np75sH Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > 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 nothin= g=20 unexpected goes wrong (software bug, hardware problem). The reason fsck works to begin with, is that it is designed to fix specific= =20 inconsistencies in the file system that are expected. The file system=20 (takling about UFS here, and other non-journaled file systems that care abo= ut=20 this stuff) is designed very carefully such that certain correctable=20 inconsistencies happen, while preventing those that are not correctable. That is, under fully expected circumstances, UFS is intended to require fsc= k=20 on reboot. But it is NOT intended that fsck find unexpected inconcistencies= =20 and ask for operator intervention. What happens in the event of write caching + power failure, software bug or= =20 hardware bugs, is that you end up with semi-random inconsistencies. fsck=20 *may* be able to patch the situation enough for the file system to be usabl= e,=20 but fundamentally all bets are off. > First step surely is to *disable* write caching if you have drives that > are doing it? =46or 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=20 ext2fs; not sure). It is enough that the system does not break the file=20 system's ability to guarantee ordering of certain critical operations, whic= h=20 is why write caching causes a problem (the drive re-orders writes for=20 performance and you end up with B happening before A, but consistency=20 depended on B happening AFTER A). =2D-=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --nextPart1219279.2iA4np75sH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHWjuCDNor2+l1i30RAvBUAKCDBrruwY4SePsrR2SSSF+KF0BmyACcCDxz tidDRwnoGx83fixmTRtv0zs= =n3UT -----END PGP SIGNATURE----- --nextPart1219279.2iA4np75sH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712080736.50433.peter.schuller>