Date: Wed, 24 Sep 1997 05:26:32 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: brandon@roguetrader.com (Brandon Gillespie) Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Known problems with async ufs? Message-ID: <199709240526.WAA02832@usr07.primenet.com> In-Reply-To: <Pine.BSF.3.96.970923120909.1067A-100000@roguetrader.com> from "Brandon Gillespie" at Sep 23, 97 12:11:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Just curious, I have gotten the general impression that async UFS is > unstable, simply because everybody says you really want to use sync > UFS, which is horribly slower than async ufs. If your BOX is on a UPS, > and you are generally assured that nothing is going to cause it to simply > 'go down', why WOULDNT you want to run async on ALL filesystems? What > problems are there with it? The reason behind this statement is based on recoverability in case of failure. If you can guard against failure (including automatic orderly shutdown by your IPS), then this shouldn't be a problem for you. The reality is that fsck can only deterministically recover from one failed metadata operation. Anything more than one, and you will probably end up with metadata errors. For example, if you had 10 metadata operations outstanding at a time, you would have only a 1 in 1024 chance of fsck "guessing right" and putting the FS into the state where it would have been had there not been a failure. If you have 10 operations outstanding during a crash, 1 to 10 files will be damaged. Probably 7, actually, based on 3 out of 7 of them being parent/child directory operations. Synchronus metadata writes guarantee the ordering of metadata updates do that at most one file will be damaged, and that damage will be recoverable (since there is only one way the operation can go: it's deterministic for one operation away from sync'ed state). Other ways of making the same ordering guarantees are delayed ordered writes (patent pending USL; EXT2FS uses a similar technology; I don't know if it's infringing), persistent cache writes (like the hardware NVRAM producs for SBUS machines, etc.) where the RAM that caches the metadata writes doesn't go away on failure, and Soft Updates (from the Ganger/Patt paper from the University of Kentucky). Of these, Synchronus writes are slowest, DOW is next slowest, Soft Updates is within 5% of memory speed for bursty traffic, and NVRAM is fastest (but requires special hardware and serious FS modifications). If you can guarantee an orderly shutdown on power failure because you have a daemon that supports your UPS and your UPS allows monitoring the line status (like an APC525, for example, but *not* an APC200, which doesn't have a serial port), then it's much safer to run async; of course, you are still screwed if your power supply fails, and you aren't in the Soft Updates or NVRAM cases. That answer the question? Regards, 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?199709240526.WAA02832>