Return to BSD News archive
Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!newsfeed.internetmci.com!EU.net!sun4nl!rnzll3!sys3.pe1chl!rob From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux Reply-To: pe1chl@wab-tis.rabobank.nl Organization: PE1CHL Message-ID: <DMv8w7.8H4@pe1chl.ampr.org> References: <4er9hp$5ng@orb.direct.ca> <4fg8fe$j9i@pell.pell.chi.il.us> <311C5EB4.2F1CF0FB@freebsd.org> <4fjodg$o8k@venger.snds.com> <4fo1tu$n31@news.jf.intel.com> <DMrCE4.3HF@pe1chl.ampr.org> <4ftjt9$fjs@park.uvsc.edu> Date: Fri, 16 Feb 1996 11:21:42 GMT Lines: 60 Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14374 comp.os.linux.development.system:18042 In <4ftjt9$fjs@park.uvsc.edu> Terry Lambert <terry@lambert.org> writes: >rob@pe1chl.ampr.org (Rob Janssen) wrote: >] The claim is that the synchronous metadata updates are undesirable, >] because they slow down the system, and whatever consistency advantages >] they are said to have only make it more likely that fsck will report no >] errors, and don't improve the situation w.r.t. bogus data. >Let us agree that synchronus updates are undesirable. >Let us also agree that the UFS use of synchronus updates is as >a simple method of ensuring write ordering without violating >patents or rewriting a lot of code. >Let us discuss the desirability of order metadata writes. The BSD people are stressing the importance of the order of metadata writes all the time. Is it *really* true that the UFS filesystem can be completely destroyed by incorrectly ordered metadata writes? I think the worst that can happen is the destruction of a single file which has been created just before the crash. As we have already seen, such files are in jeopardy anyway, as the data writes are not synchronous. Ensuring integrity of the metadata information and then truncating the file because the data was not written (or: having a file with incorrect data) is not going to help anyone. As far as I know, the system has directory files which map names to inode numbers, inodes which store file attributes and map file positions to block numbers, and a free space map which administers free space on the device for efficiency reasons (so that the system does not have to examine all inodes to know which blocks are free). fsck should be able (and on my Linux system, always has been) to detect inconsistencies between the above three metadata items and fix the inconsistencies by removing the file, or linking it into lost+found, or adjusting the free space administration. No matter which item was written first, and which item was not written at all because of the crash. No inode written -> directory points to free inode and file is removed. allocated blocks are not accounted for, and added to free space map. No file entry written -> inode is unreferenced and linked into lost+found No freespace map updated -> inode points to free blocks, either the blocks are marked allocated or the file is truncated. So, what is it that synchronously updating metadata is really buying you? When the answer is "nothing, really" and it does slowdown the system, I don's see why I would use it. When you want to use it, go ahead. Rob -- +------------------------------------+--------------------------------------+ | Rob Janssen rob@knoware.nl | BBS: +31-302870036 (2300-0730 local) | | AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU | +------------------------------------+--------------------------------------+