Subject: Re: LFS frailty vs. datestamping [Was Re: /dev/clock pseudodevice]
To: Bill Studenmund <email@example.com>
From: Timothy E. Denehy <firstname.lastname@example.org>
Date: 07/30/2001 14:29:50
> 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.
If the same blocks are modified repeatedly at a sufficent rate, the updates
will be absorbed by the buffer cache, and LFS will not write out each block
each time. Furthermore, if the modified blocks are selected randomly from the
file, FFS will perform a number of random writes when the blocks are flushed
from the cache, whereas LFS will coalesce these blocks into a sequential write,
and therefore LFS write performance will be much better.
> 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. :-)
The same argument applies here.