Date: Sat, 29 Mar 2003 20:05:16 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "Pedro F. Giffuni" <giffunip@yahoo.com> Cc: freebsd-fs@FreeBSD.org Subject: Re: LFS vs FFS Message-ID: <3E866CFC.73C3C7E@mindspring.com> References: <20030330023243.79591.qmail@web13404.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Pedro F. Giffuni" wrote: > The NetBSD guys compared FFS and LFS here: > http://mail-index.netbsd.org/tech-kern/2003/03/30/0001.html > > "LFS beats FFS+softdep hands down, which is not > surprising." That was from an tar extraction shirt sleeve "benchmark"; I would expect this to be the case, since it could just write extents. If you notice, the wall time is the killer; this is related to the soft updates synchronization clock latency stall. It can be reduced significantly by making more clock wheel entries, or accellerating the rotation of the clock wheel under certain load circumstances (very high load or very low load -- one of the things I would suggest for a "soft read-only" implementation, for example, would be, if there was a small amount of I/O, spin it out fast, to get the system to the quiescent point faster, and, incidently,more frequently, and for longer delta intervals). You can't eliminate it completely; by encoding operations ordering in the log, LFS wins out because it doesn't delay the writes: it's just dumps the operations out in order, to the log, not caring about anythong other than the timestamp being monotonically increasing. Later down, the message has "bonnie" benchmark output, which is a mixed load benchmark, making it more representative of a potential real-world load than the shirt-sleeve variety. I expect that the log-thrashing which happens in LFS could benefit from independent operation co-ordering, meaning if it maintained a dependency list, and introduced a small latency, rather than an update clock, it could "gather" the writes of log entries much more effectively. One of the comments he makes in the posting you reference is about the "filesystem near full" case requiring exponentially increasing time from the cleaner (which should also act as a defragger). The back-pressure on the FS from the cleaner needing to be run to recover reusable extents from those out there is probably a significant issue -- as significant as the back-pressure on soft updates, following a very large delete. Some of the work done to stall operations, rather than fail them, in the presence of this back-pressure, which has been done for soft updates is probably also applicable to LFS, FWIW. > I think FFS should do colocation but since there is so > little (no) interest, perhaps it's a good time to port > LFS: > > "A preliminary conclusion is that LFS is now pretty > stable for normal usage (although I didn't create any > disk-nearly-full situations which make LFS' life > hard), and then it does quite well. The write > case is worth some investigation." > > Do your own comparisons though ;). I would like to see LFS technology revived in FreeBSD; it was killed unfairly, IMO, through poor maintenance, though the lack of a "cleaner" at the time was a good excuse to not maintain the code. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E866CFC.73C3C7E>