Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!spool.mu.edu!pravda.aa.msen.com!nntp.coast.net!howland.reston.ans.net!newsfeed.internetmci.com!news.mathworks.com!uunet!in1.uu.net!news.artisoft.com!not-for-mail From: mday@elbereth.org (Matt Day) Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux Date: 6 Mar 1996 14:27:59 -0700 Organization: none Lines: 90 Message-ID: <4hl00v$7it@coyote.Artisoft.COM> References: <DnoqB4.2sy@pe1chl.ampr.org> <4hirl9$nr7@gizmo.nas.nasa.gov> <Dnu8FD.CK2@pe1chl.ampr.org> NNTP-Posting-Host: coyote.artisoft.com Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14866 comp.os.linux.development.system:18654 In article <Dnu8FD.CK2@pe1chl.ampr.org> pe1chl@wab-tis.rabobank.nl writes: >In <4hirl9$nr7@gizmo.nas.nasa.gov> truesdel@gizmo.nas.nasa.gov (Dave Truesdell) writes: > >>The point you seem to want to ignore is, while data integrity is not >>guaranteed, it only affects those files being written at the time of a >>crash. If you don't guarantee metadata integrity, you could loose *every* >>file on an active filesystem. > >Please show us how that can happen, and how sync metadata is going to >avoid it. I think you are only spreading FUD. >(or is there some inherent fragility in FFS that is not in the classic >UNIX filesystems and ext2fs?) There appears to be some confusion about exactly why sequenced metadata updates are necessary. I have previously recommended that everybody read the fine technical reports (RTFTR?) on the subject, but that didn't seem to end the confusion. So, I will summarize the facts from the technical reports, and perhaps that will end the confusion. This summary was derived from Ganger and Patt's "Soft Updates: A Solution to the Metadata Update Problem in File Systems" paper, which you can find here: http://www.pdos.lcs.mit.edu/~ganger/papers/CSE-TR-254-95/ There are three main structural changes requiring sequenced metadata updates: block allocation, block deallocation, and link removal. (It is worth noting that a fourth structural change, link addition, does not require sequenced metadata updates to protect file system integrity, assuming you always run fsck before mounting a file system. But, as the Soft Updates paper describes, if as many metadata updates as possible are sequenced, the need to run fsck almost disappears.) Block Allocation ---------------- When a new block or fragment is allocated for a file, the new block pointer, whether in the inode or an indirect block, should not be written to stable storage until after the block has been initialized. If the new block pointer is written to stable storage before the block it points at has been initialized and the system suddenly crashes, then when the system comes back up the file will contain an uninitialized block of data. Thus, we can see in this case that file corruption can occur on file systems that do not sequence their metadata updates. Block Deallocation ------------------ Deallocated blocks must not be reused before previous on-disk pointers to them have been reset. If a deallocated block is reused before the on-disk pointers to it have been reset and the system suddenly crashes, then when the system comes back up the fsck utility will discover a block on disk that is allocated to more than one file at the same time, and fsck will not be able to figure out which file the block is really supposed to be allocated to. (And it's very unlikely that the system administrator would know, either.) Thus, we can see in this case that a serious file system inconsistency (one which fsck cannot fix) can occur on file systems that do not sequence their metadata updates. Link Removal ------------ When removing a directory entry, the on-disk inode should not be reinitialized or pointed to by a new on-disk directory entry before all previous on-disk directory entry pointers to it have been nullified. If an on-disk inode is pointed to by a new on-disk directory entry before the previous on-disk directory entries have been nullified and the system suddenly crashes, then when the system comes back up the fsck utility will discover an on-disk inode that is pointed at by two different directory entries, and fsck will not be able to figure out which directory entry the inode really belongs to. (And it's unlikely that the system administrator would know, either.) Thus, we can see in this case that a serious file system inconsistency (one which fsck cannot fix) can occur on file systems that do not sequence their metadata updates. Of course, depending on the particular file system, this may not be an exhaustive list of the structural changes needing sequenced metadata updates. But you get the general idea. Just follow these rules: 1) Never reset the old pointer to a resource before the new pointer has been set (when moving objects), 2) Never reuse a resource before nullifying all previous pointers to it, and 3) Never point to a resource before it has been initialized. Matt Day <mday@elbereth.org>