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!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!news.ysu.edu!usenet.ins.cwru.edu!gatech!news.mathworks.com!news.kei.com!nntp.coast.net!howland.reston.ans.net!ix.netcom.com!netcom.com!jlemon From: jlemon@netcom.com (Jonathan Lemon) Subject: Re: async or sync metadata [was: FreeBSD v. Linux] Message-ID: <jlemonDMp409.4sr@netcom.com> Organization: NETCOM On-line Communication Services (408 261-4700 guest) References: <4er9hp$5ng@orb.direct.ca> <4fjodc$o8j@venger.snds.com> <jlemonDMMDq5.1yF@netcom.com> <DMnow5.43G@pe1chl.ampr.org> Date: Tue, 13 Feb 1996 03:50:32 GMT Lines: 58 Sender: jlemon@netcom22.netcom.com Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:13654 comp.os.linux.development.system:17191 In article <DMnow5.43G@pe1chl.ampr.org>, Rob Janssen <pe1chl@wab-tis.rabobank.nl> wrote: >In <jlemonDMMDq5.1yF@netcom.com> jlemon@netcom.com (Jonathan Lemon) writes: > >>In article <4fjodc$o8j@venger.snds.com>, >>Michael Griffith <grif@hill.ucr.edu> wrote: >>>|In article <DMI5Mt.768@pe1chl.ampr.org>, >>>|Rob Janssen <pe1chl@wab-tis.rabobank.nl> wrote: >>>|>It seems to be very hard to get this misconception out of the BSD people's >>>|>heads... >>>|>Sync metadata writes may seem to improve things, but actually it just >>>|>causes your fsck's to return no errors while the files are still >>>|>corrupted. Not necessarily better. >>> >>>Very hard indeed. Here it is one more time: >>> >>> sync metadata with async data is not just slower, >>> it is LESS SAFE. This behavour should not be the default >>> on any reasonable system. If you want real safety, >>> then both data and meta need to be synchronous (i.e. no >>> buffer cache for writes). This real safety comes with >>> an huge performance hit (as in MSDOS). > >>Um, Michael, Rob? Sync metadata just insures that the _filesystem_ is always >>in a consistent state, not the data itself. It is safer in the sense that >>you don't lose the entire filesystem, not that you don't lose data. > >Essentially, with sync metadata you will have to remove all recently >modified files off your disk after a crash, because you cannot be sure >of the validity of their contents. I'm not sure what you're arguing here, but any write-behind filesystem has the potential for dataloss, including logging filesystems. So "removing all recently modified files" is a bogus argument, as it can apply to any FS that does write-behind for saving data. >With ext2fs you won't lose the entire filesystem just because some >metadata is not in a consistent state. fsck will fix that, and you will >know about it (instead of having some false trust that everythink is OK). >I don't know how FFS behaves in this regard, it may be true that you >lose your entire filesystem if some inode or free space map has not been >properly updated, but that would not be a clever design IMHO. Metadata problems in FFS are fixed by fsck when it runs, since FFS takes extreme care to guarantee that metadata is always valid. Even if the system crashes while writing metadata, there is no user-visible corruption of the filesystem. (eg, getting someone else's files) This is due to the fact that the sync writes guarantee the ordering of the metadata, and the metadata modifications are ordered in such a way that the FS is always in a recoverable state. I haven't examined ext2fs, so I won't comment on it. I think Jordan got it right when he suggested a "pull the plug" test. This thread is getting a little tired. :-) -- Jonathan