Re: [PATCH] reiserfs: on-demand bitmap loading (testing only)

[Jeffrey Mahoney <jeffm@suse.com>]

David Masover wrote:
> Pierre Etchemaïté wrote:
> 
>> Le Thu, 7 Jul 2005 13:59:35 -0400, studdugie <studdugie@gmail.com> a
>> écrit :
>>
>>
>>> I agree w/ Jeff 100%. I'm not a kernel hacker, simply a user. As a
>>> matter of fact, I was one of those people that Jeff aluded to when he
>>> said: "There have been reports of large filesystems taking an
>>> unacceptably long time to mount."
>>
>>
>>
>> That also makes reiserfs uncomfortable with automount devices, specially
>> if they're bandwidth limited like external USB or firewire disks...
> 
> 
> USB and firewire disks already take a little long to mount anyway.
> 
> But, it is definitely a performance enhancement, or at least a tweak.
> I'd like to see it happen -- it takes 10-15 seconds to mount my 200 gig
> Reiser4 partition, which is unacceptabe for a desktop machine -- at
> least, for a *linux* desktop machine.
> 
> To keep Hans happy about the "default case", can we load the bitmap in
> the background during boot/mount?  Basically, if it's loaded on demand,
> then we pretend to demand each part of it, one by one.  Would that
> considerably slow normal FS operation?  Could we defer it to when the
> disk is idle?  (*disk*, not FS)

Hi David -

The main issue I have with this is that I don't think bitmaps should be
treated specially. They are metadata, pure and simple. We don't treat
the s-tree specially with respect to caching and it is used regardless
of whether the operations performed on the filesystem are for reads or
writes.

The root block/node sees far more activity than any bitmap and it is not
treated any differently than any other bit of metadata. It's simply
requested when it is needed. If the vm has determined that the root
block is frequently used, it stays in memory. Why should the bitmaps be
any different?

It's possible to read the bitmaps in a "delayed" fashion, but the
problem of completely wasted resources is still not addressed. I feel
the correct solution is to let the buffer cache do its job and not
assume that any particular filesystem takes priority over other resources.

-Jeff

-- 
Jeff Mahoney
SuSE Labs
jeffm@suse.com