Re: Request: I/O request recording

From: Bart Samwel
Date: Mon Jan 26 2004 - 06:51:46 EST


Andrew Morton wrote:
Bart Samwel <bart@xxxxxxxxx> wrote:

Linux caches disk data on a per-file basis. So if you preload pagecache
via the /dev/hda1 "file", that is of no benefit to the /etc/passwd file. Each one has its own unique pagecache. When reading pages for /etc/passwd
we don't go looking for the same disk blocks in the cache of /dev/hda1.

Which is why the userspace cache preloading needs to know the pathnames of
all the relevant files - it needs to open and read each one, applying
knowledge of disk layout while doing it.

Hmmm, that explains why this didn't work. :( So if I wanted to do this completely from user space using only block_dump data I'd probably have to go through all files and find out if they had any blocks in common with my preload set -- presuming there is a way to find that out, which there probably isn't. That makes this idea pretty much useless, I'm sorry to have bothered you with it.

You could certainly do that. Given disk block #N you need to search all
files on the disk asking "who owns this block". The FIBMAP ioctl can be
used on most filesystems (ext2, ext3, others..) to find out which blocks a
file is using. See bmap.c in

http://www.zip.com.au/~akpm/linux/patches/stuff/ext3-tools.tar.gz

Unfortunately you cannot determine a directory's blocks in this way. Ext3's directories live in the /dev/hda1 pagecache anyway. ext2's
directories each have their own pagecache.

I found out two things while trying to do this:

1. Many filesystems in linux set f_fsid to zero for statfs. I was trying to use this to skip over mount points, but that doesn't work. Had to use the st_dev field from stat instead. :(

2. Swapfiles apparently don't like to be touched. I did an ioctl(FIGETBSZ) on a swapfile, and it would simply block until I did a swapoff on the file. I didn't even get to the FIBMAP part. :( Is this correct behaviour? And is there any way to detect this so that I can work around it?

-- Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/