Subject: Re: LFS frailty vs. datestamping [Was Re: /dev/clock pseudodevice]
To: Bill Studenmund <firstname.lastname@example.org>
From: Manuel Bouyer <email@example.com>
Date: 07/30/2001 21:48:26
On Mon, Jul 30, 2001 at 11:35:52AM -0700, Bill Studenmund wrote:
> On Sun, 29 Jul 2001, Manuel Bouyer wrote:
> > On Sat, Jul 28, 2001 at 04:28:04PM -0700, Greywolf wrote:
> > > model, and I'm wondering why we don't do a generic logging/journaling layer
> > > that can overlay FFS (or any other filesystem we'd like journaling on, but
> > > FFS comes to mind since it and LFS are the only ones for which we run
> > > a consistency check at boot time). Perhaps I'm being a bit simplistic,
> > > and I'm SURE I'm missing something here (in which case someone will gladly
> > > thump me soundly with a clue*4, I'm sure), but in concept, it sounds like
> > > a potentially much better win than LFS is capable of providing.
> > LFS has much, much more potentials than would have a journaled FFS:
> > - stuffs like snapshots, backup of incremental changes, etc ... are
> That should be stuff. ;-)
> > realy easy to do with LFS
> > - In LFS, data are also journalised, wich is a real win for some applications.
> > Not to speack about performances, which are much better than FFS (especially
> > for a lot of small files).
> Whenever you talk about file system performance, you need to mention WHAT
> you are doing with the file system.
> LFS can do much better than FFS _on_certain_work_loads_. LFS is great for
> data which are written all at once and not modified much. Infrequent
> modification isn't bad, as the cleaner can come along and fix things. But
> for a file where the same blocks get modified over and over, FFS will do
> better than LFS. FFS just changes the existing data blocks. The only
> possible metadata change would be m & c-time updates. LFS, though, has to
> write each block out each time.
> I think something like a database receiving lots of updates would be a bad
> traffic pattern for LFS. You can get parts of the files updated tens to
> hundreds of times per second (depending on what the update rate is). While
> a bunch of those writes could get coalessed (can LFS do that?), you're
> still generating segments at a good rate. :-)
But, for this, LFS has an advantage over FFS: data are journalised, so
if your machine crash while a write was in progress, you get the database in
the previous consistent state.
It can also be very usefull for things like mail spool.
Manuel Bouyer <firstname.lastname@example.org>