Log file systems? (Was: Re: dual 400 -> dual 600 worth it?) - sol.lists.freebsd.chat

Message from discussion Log file systems? (Was: Re: dual 400 -> dual 600 worth it?)

Terry Lambert

More options Dec 14 1999, 3:00 am

Newsgroups: sol.lists.freebsd.chat

From: Terry Lambert <tlamb...@primenet.com>

Date: 1999/12/14

Subject: Re: Log file systems? (Was: Re: dual 400 -> dual 600 worth it?)

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

> >> Also -- and this is just curiosity, why did we go with soft updates
> >> instead of finishing lfs? Aside from the fact that soft updates
> >> appears cleaner than lfs, is there any outstanding superiority of one
> >> over the other?

> >These are FAQs - instead of wasting peoples cycles in explaining it again

> I'm sure you're right, but I couldn't find the answer in the FAQ I
> supped this morning. Is there a different FAQ?

They are FAQs, not "in the FAQ".

The archives you should be looking at, and the place you should be
asking the question are the freebsd-fs list.

Soft Updates was implemented because Whistle paid Kirk to do the
work, as well as throwing in some of Julians time and my time in
the bargain. The reason for doing the work was to get rid of the
UPS circuitry and heavy battery in the next generation Whistle
InterJet product.

LFS wasn't finished because the implementation is incomplete (but
only minorly so), and because it was not kept up to date with VM
and other system interface changes (IMO: you change the interface,
you're responsible for fixing all the code that uses it). The
minor missing piece was a "cleaner" daemon to follow behind and
reclaim logs that are no longer referenced by inodes. It's pretty
trivial to write one of these.

Frankly, logging solves different problems than soft updates, and
the technology is orthogonal. Soft Updates solves the metadata
ordering problem, without requiring synchronous writes. The LFS
solves the fast recovery following a crash problem; it does this
at the cost of a latency between when disk space is no longer
being used, and when it becomes available for reuse, as well as
adding in a certain level of fragmentation (the cleaner also needs
to be a defragger, for a small definition of defragger).

Soft Updates is capable of being generalized to allow dependencies
to span file system layers, including externalizing a generalized
transactioning interface to user space (Very Useful). Logging is
a raw disk management mechanism.

> Still, I didn't find
> anything that explained the decision to go with soft updates. Perhaps
> I missed the relevant threads. Were they prior to '98?

Soft Updates came in because someone paid for its developement;
there is a bit of difference between the Ganger/Patt implementation,
and the one in FreeBSD, but not a huge amount. It leverages greatly
on work Kirk had already done for BSDI and OpenBSD.

Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majord...@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message

Reply to author Forward