From: Bart Samwel <bart@samwel.tk>
To: Andrew Morton <akpm@osdl.org>
Cc: felix-kernel@fefe.de, linux-kernel@vger.kernel.org
Subject: Re: Request: I/O request recording
Date: Mon, 26 Jan 2004 12:50:24 +0100 [thread overview]
Message-ID: <4014FF00.1020106@samwel.tk> (raw)
In-Reply-To: <20040125153803.4d7e1015.akpm@osdl.org>
Andrew Morton wrote:
> Bart Samwel <bart@samwel.tk> 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
next prev parent reply other threads:[~2004-01-26 11:50 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-24 18:10 Request: I/O request recording Felix von Leitner
2004-01-24 18:23 ` Valdis.Kletnieks
2004-01-24 18:26 ` Arjan van de Ven
2004-01-24 19:25 ` Ville Herva
2004-01-24 22:43 ` Arjan van de Ven
2004-01-24 20:11 ` Diego Calleja
2004-01-24 21:09 ` Ville Herva
2004-01-24 23:35 ` Andrew Morton
2004-01-24 23:53 ` Davide Libenzi
2004-01-25 0:03 ` Andrew Morton
2004-01-25 0:09 ` Davide Libenzi
2004-01-25 0:04 ` Valdis.Kletnieks
2004-01-25 0:10 ` Davide Libenzi
2004-01-25 12:26 ` Felipe Alfaro Solana
2004-01-25 22:59 ` Bart Samwel
2004-01-25 23:09 ` Andrew Morton
2004-01-25 23:29 ` Bart Samwel
2004-01-25 23:38 ` Andrew Morton
2004-01-26 0:23 ` Diego Calleja García
2004-01-26 0:32 ` Andrew Morton
2004-01-26 11:50 ` Bart Samwel [this message]
2004-01-26 11:57 ` Andrew Morton
2004-01-27 19:13 ` Bart Samwel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4014FF00.1020106@samwel.tk \
--to=bart@samwel.tk \
--cc=akpm@osdl.org \
--cc=felix-kernel@fefe.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.