Date: Wed, 03 Mar 1999 11:08:57 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: Harold Gutch <logix@foobar.franken.de> Cc: freebsd-advocacy@FreeBSD.ORG Subject: Re: The Linux PR firestorm disaster (w.r.t. FreeBSD) Message-ID: <36DC99B9.1E2BB9A@newsguy.com> References: <Pine.BSF.4.05.9903020901310.3311-100000@gwdu60.gwdg.de> <36DC09E3.2F959909@thuntek.net> <19990302184800.B4386@foobar.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Harold Gutch wrote: > > Is there some real good comparism of all the three, like in what > case you might lose data with each of the three possibilities > (according to that posting, there's a small chance of data-loss > with synchronous writes, so I guess that it's the same for > softupdates, too) and (rough) speed-comparisms of them ? Well, I think it goes down like this: There are two kinds of write: metadata writes and data writes. Data is the information that goes inside the files. Metadata concerns the structure of the filesystem. Data loss implies having data supposedly written being lost in case of panic/power failure/etc. As the data would be lost anyway, this only matters in case the application depends on it to ensure data consistency. If it does, it ought to be using fsync(), so, again, it wouldn't matter. Metadata loss implies having metadata supposedly written being lost. As a result, you could have files pointing to unallocated data, allocated data not being pointed by files, etc. Now, remember that it is impossible to *prevent* any kind data loss through the use of any algorithms. If some kind of data is bound to be written and the system crashes right before the write is requested, there is simply no way you could have prevented loosing that information, right? What is important, then, is how much damage is done. As I understand, FreeBSD's ufs have three "sync" states. Normal mount, async and sync. And here are the trade-offs: Sync mount: data and metadata are written immediately. Whoever requested the write is blocked until the data is safely on the disk (or maybe unsafely on the disk cache, actually -- but it doesn't pay to go into this here). In case of crash, you can have one level of metadata loss. For example, you could have a directory created but with nothing pointing to it, or unreferenced allocated data. This is a *recoverable* state, because you never got so screwed up that your file system gets completely hosed. Normal mount: data is written asynchronously, metadata is written synchronously. This way, you still can get into an inconsistent data state, but your metadata loss is still restricted to one level. Async mount: everything is written asynchronously. This means that the filesystem can get into a state so inconsistent that you will be unable to recover it except through a very arduous manual procedure. Ok, now, for softupdates. Softupdates is similar to an async mount, with one huge difference. The data is written to the disk in an *ordered* way. This order is chosen so that the consistency of the filesystem structure is always equivalent to that of sync mounts. Actually, it is better, since the sync mount doesn't actually order the writes to garantee the level of consistency that softupdates does. This gives you async speed (almost) with sync safety (a little better). In fact, because of the way softupdate works, in some scenarios you get performance *better* than async mount, because softupdates coalesces metadata writes. So, instead of writing some piece of metadata to create four inodes by writting the same block four times, it could turn these four writes into a single one. Does that sound too good to be true? Sorry, we can't do anything about it. "Unfortunately," it is that good, believe it or not. :-) So, you ask, why is everybody still running the other kinds of mounts? Well, for one, there is the license. Softupdates is not under a BSD license. Also, there are some very specific cases where async mounts are superior. Aside from that... beats me! :-) AFAIK, everyone who knows about softupdates and doesn't have problems with the license is running it. :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "FreeBSD is Yoda, Linux is Luke Skywalker." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36DC99B9.1E2BB9A>