Re: Getting FS access events

[Richard Gooch <rgooch@ras.ucalgary.ca>]

Linus Torvalds writes:
> 
> On Sun, 13 May 2001, Richard Gooch wrote:
> >
> >   Hi, Linus. I've been thinking more about trying to warm the page
> > cache with blocks needed by the bootup process. What is currently
> > missing is (AFAIK) a mechanism to find out what inodes and blocks have
> > been accessed. Sure, you can use bmap() to convert from file block to
> > device block, but first you need to figure out the file blocks
> > accessed. I'd like to find out what kind of patch you'd accept to
> > provide the missing functionality.
> 
> Why would you use bmap() anyway? You CANNOT warm up the page cache
> with the physical map nr as discussed. So there's no real point in
> using bmap() at any time.

Think about it:-) You need to generate prefetch accesses in ascending
device bnum order. So the bmap() is there to tell you those device
bnums. You'd still prefetch using file bnums, the the *ordering* is
done based on device bnum. In fact, once the list is sorted, you can
chuck out the device bnums. You only need to store inum/path and file
bnum in the database.

> > One approach would be to create a new ioctl(2) for a FS that would
> > read out inum,bnum pairs.
> 
> Why not just "path,pagenr" instead? You make your instrumentation save
> away the whole pathname, by just using the dentry pointer. Many
> filesystems don't even _have_ a "inum", so anything less doesn't work
> anyway.

Sure, this would work too. I'm a bit worried about the increased
amount of traffic this will generate.

> Example acceptable approach:
> 
>  - save away full dentry and page number. Don't make it an ioctl. Think
>    "profiling" - this is _exactly_ the same thing, and profiling uses a
> 	(a) command line argument to turn it on
> 	(b) /proc/profile
>    (and because you have the full pathname, you should just make the dang
>    /proc/fsaccess file be ASCII)

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?
Remember, we want to do this on every boot (to keep the database as
up-to-date as possible).

>  - add a "prefetch()" system call that does all the same things
>    "read()" does, but doesn't actually wait for (or transfer) the
>    data. Basically just a read-ahead thing. So you'd basically end up
>    doing
> 
> 	foreach (filename in /proc/fsaccess)
> 		fd = open(filename);
> 		foreach (sorted pagenr for filename in /proc/fsaccess)
> 			prefetch(fd, pagenr);
> 		end
> 	end

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.

> Forget about all these crappy "ioctl" ideas. Basic rule of thumb: if
> you think an ioctl is a good idea, you're (a) being stupid and (b)
> thinking wrong and (c) on the wrong track.

Don't hold back now. Tell us what you really think :-)

> And notice how there's not a single bmap anywhere, and not a single
> "raw device open" anywhere.

I don't mind the /proc/fsaccess approach, I'm just worried about the
overhead of doing the denty->pathname conversions on each fault/read.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca