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. :-)

Take care,

Bill