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

[David Masover <ninja@slaphack.com>]

Jeffrey Mahoney wrote:
> 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.

This is the philosophical reason why I like on-demand loading.  There's 
also the immediate speedup of boot.

But, I think Hans has a point that it may be better for performance to 
pre-cache them.  I would rather the default behavior be to load them on 
demand, but I can see situations where people would choose to pre-cache 
them, or even (as we do now) force them to stay in kernel memory as long 
as the FS is mounted.  But that's not a sane default.

Big hard drives on desktop machines are getting more and more common, 
and even the lowly Linux gamer doesn't want to waste the RAM he bought 
for Doom 3 on a 200 gig filesystem when he's only using 1.5 gigs of it 
at the moment.

I would guess that this is a lot more common of a scenario than massive 
2TB arrays where people can throw money (RAM) at the system to make it 
faster, in any way they can.  But even if it's not, people with 2TB 
arrays are much more likely to discover the precaching feature and turn 
it on than gamers / desktop users woud be to discover it and turn it off.

And besides, for the average desktop machine, it's latency that matters 
more than throughput.  The most noticeable latency that we can optimize 
for is boot time, the next most noticeable is launching a new app / 
changing apps.  For the average desktop user, it doesn't matter if it 
takes an extra half second to load a chunk of the bitmap in order to 
load apps, and it certainly doesn't matter if it takes an extra tenth of 
a second to load a file, but it does matter if RAM wasteage pushes an 
app into swap and it takes 5-10 seconds (at least) to switch apps, and 
it does matter if it takes 5-10-20 seconds longer to boot.

That is why I think on-demand should be default.

> 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?

Because bitmaps are harder to seek to?  I think that's the argument -- 
the bitmap is going to be pushed out of memory because it's used less 
frequently, but it'll take much longer to load than anything else 
because it's spread over the disk.

But, you could make a similar argument about most files.

I second the request for benchmarks.