Date: Sat, 10 Feb 1996 13:02:21 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: imp@village.org (Warner Losh) Cc: terry@lambert.org, coredump@onyx.nervosa.com, current@FreeBSD.ORG Subject: Re: How Message-ID: <199602102002.NAA16375@phaeton.artisoft.com> In-Reply-To: <199602100543.WAA25958@rover.village.org> from "Warner Losh" at Feb 9, 96 10:43:06 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> : To allow your system to *always* be recoverable (even if data writes > : to open files may be lost), you should mount sync. > > Except when the meta data writes fail, of course... You mean a hardware failure, right? A single failed metadata write as a result of a crash before the write completes is *always* recoverable with fsck. A hardware failure will either transparently forward the failed sector, or if bad sector forwarding is being handled in software, the BAD144 layer will cause the soft bad block map to be updated and, again, the failed write will be remapped. For read failures, the effect is also always recoverable, though it may take several passes on fsck (I posted a recent patch to fsck's dynamic lost+found creation to reduce the number of passes by one). The real problem becomes soft forwarding on corrupt media in the FS structure data. This is actually fixable by imposing the media perfection below the "disklabel" mechanism -- a pro-devfs argument, actually, since that's one approach to doing that. > : For anything other than initial install, copying, archiving, async > : is a bad bet. For those particular operations, it's a big win. > > It can also be good on a partition devoted solely to news that is > allowed to be newfs on data corruption as well... Yes. I missed non-persistant FS's, like /tmp, in my list... whether or not news persistance is an issue for you is very dependent on how much you would have to re-mirror from your feed, the transport speed over which your feed arrives, and the level of acceptability of dropping local postings prior to the crash into the bit-bucket if they didn't get sent out. Personally, I like log structuring, journalling, and delayed-ordered writes better than I like async as a soloution to the metadata "speed problem". Without such a machanism, it's a trade you have to make as an administrative decision. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602102002.NAA16375>