Hi,
We have file readahead to do asyn file read, but has no metadata
readahead. For a list of files, their metadata is stored in fragmented
disk space and metadata read is a sync operation, which impacts the
efficiency of readahead much. The patches try to add meatadata readahead
for btrfs. It has two advantages. One is make metadata read async, the
other is significant reducing disk I/O seek.
In btrfs, metadata is stored in btree_inode. Ideally, if we could hook
the inode to a fd so we could use existing syscalls (readahead, mincore
or upcoming fincore) to do readahead, but the inode is hidden, there is
no easy way for this from my understanding. Another problem is we need
check page referenced bit to make sure if a page is valid, which isn't
ok doing this in fincore/mincore. And in metadata readahead, filesystem
need specific checking like the patch4. Doing the checking in current
API (for example fadvise) will mess things too. So we add two ioctls for
this. One is like readahead syscall, the other is like micore/fincore
syscall.
Under a harddisk based netbook with Meego, the metadata readahead
reduced about 3.5s boot time in average from total 16s.
v2->v3:
1. fixed some issues Arnd pointed out
2. rebased to latest git
3. remove the 'updated' page flag check from patch 2 as suggested by
Fengguang.
v1->v2:
1. Added more comments and fix return values suggested by Andrew Morton
2. fix a race condition pointed out by Yan Zheng
initial post:
http://marc.info/?l=linux-fsdevel&m=129222493406353&w=2
Thanks,
Shaohua
On Wed, 19 Jan 2011 09:15:15 +0800
Shaohua Li [off-list ref] wrote:
We have file readahead to do asyn file read, but has no metadata
readahead. For a list of files, their metadata is stored in fragmented
disk space and metadata read is a sync operation, which impacts the
efficiency of readahead much. The patches try to add meatadata readahead
for btrfs. It has two advantages. One is make metadata read async, the
other is significant reducing disk I/O seek.
In btrfs, metadata is stored in btree_inode. Ideally, if we could hook
the inode to a fd so we could use existing syscalls (readahead, mincore
or upcoming fincore) to do readahead, but the inode is hidden, there is
no easy way for this from my understanding. Another problem is we need
check page referenced bit to make sure if a page is valid, which isn't
ok doing this in fincore/mincore. And in metadata readahead, filesystem
need specific checking like the patch4. Doing the checking in current
API (for example fadvise) will mess things too. So we add two ioctls for
this. One is like readahead syscall, the other is like micore/fincore
syscall.
Has anyone looked at implementing this for filesystems other than
btrfs? Have the ext4 guys taken a look? Did they see any impediments
to implementing it for ext4?
Under a harddisk based netbook with Meego, the metadata readahead
reduced about 3.5s boot time in average from total 16s.
That's a respectable speedup. And it *needs* to be a good speedup,
given how hacky all of this is!
But then.. reducing bootup time on a laptop/desktop/server by 3.5s
isn't exactly a world-shattering benefit, is it? Is it worth all the
hacky code?
It would be much more valuable if those 3.5 seconds were available to
devices which really really care about bootup times, but very few of
those devices use rotating disks nowadays, I expect?
On Wed, Jan 19, 2011 at 2:34 PM, Andrew Morton
[off-list ref] wrote:
It would be much more valuable if those 3.5 seconds were available to
devices which really really care about bootup times, but very few of
those devices use rotating disks nowadays, I expect?
And don't rotating disk modules read and buffer whole tracks, doing
their own readahead, anymore, anyway? Isn't that part of what "on-disk
cache" does?
On Thu, 2011-01-20 at 05:33 +0800, David Nicol wrote:
On Wed, Jan 19, 2011 at 2:34 PM, Andrew Morton
[off-list ref] wrote:
quoted
It would be much more valuable if those 3.5 seconds were available to
devices which really really care about bootup times, but very few of
those devices use rotating disks nowadays, I expect?
And don't rotating disk modules read and buffer whole tracks, doing
their own readahead, anymore, anyway? Isn't that part of what "on-disk
cache" does?
The disk readahead and the metadata readahead is completely different,
you didn't even look at the patch or log before saying this.