> 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 <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org
signature.asc
Description: This is a digitally signed message part.
