Re: Getting FS access events

[Richard Gooch]

Linus Torvalds writes:
> 
> On Sun, 13 May 2001, Richard Gooch wrote:
> > 
> > Think about it:-) You need to generate prefetch accesses in ascending
> > device bnum order.
> 
> I seriously doubt it is worth it.
> 
> Th ekernel will do the ordering for you anyway: that's what the
> elevator is, and that's why you have a "prefetch" system call (to
> avoid the synchronization that kills the elevator). And you'll end
> up wanting to pre-fetch on virtual addresses, which implies that you
> have to open the files: I doubt you want to have tons of files open
> and try to get a "global" order.

OK, provided the prefetch will queue up a large number of requests
before starting the I/O. If there was a way of controlling when the
I/O actually starts (say by having a START flag), that would be ideal,
I think.

> But sure, you can use bmap if you want. It would be interesting to
> hear whether it makes much of a difference..

I doubt bmap() would make any difference if there is a way of
controlling when the I/O starts.

However, this still doesn't address the issue of indirect blocks. If
the indirect block has a higher bnum than the data blocks it points
to, you've got a costly seek. This is why I'm still attracted to the
idea of doing this at the block device layer. It's easy to capture
*all* accesses and then warm the buffer cache.

So, why can't the page cache check if a block is in the buffer cache?

> > Sure, this would work too. I'm a bit worried about the increased
> > amount of traffic this will generate.
> 
> No increased traffic. "path" is a pointer (to a dentry), ie 32
> bits. "ino" is at least 128 bits on some filesystems. You make for _less_
> data to save.
> 
> > So on every page fault or read(2) call, we have to generate the full
> > path from the dentry? Isn't that going to add a fair bit of overhead?
> 
> You just save the dentry pointer. You do the path _later_, when
> somebody reads it away from the /proc file.

That opens up a nasty race: if the dentry is released before the
pointer is harvested, you get a bogus pointer.

> > I don't see the advantage of the prefetch(2) system call. It seems to
> > me I can get the same effect by just making read(2) calls in another
> > task. Of course, I'd need to use bmap() to generate the sort key, but
> > I don't see why that's a bad thing.
> 
> Try it. You won't be able to. "read()" is an inherently
> synchronizing operation, and you cannot get _any_ overlap with
> multiple reads, except for the pre-fetching that the kernel will do
> for you anyway.

How's that? It won't matter if read(2) synchronises, because I'll be
issuing the requests in device bnum order.

				Regards,

					Richard....
Permanent: [e-mail]
Current:   [e-mail]