* Re: [PATCH v3 0/5]add new ioctls to do metadata readahead in btrfs
[not found] <1295399715.1949.863.camel@sli10-conroe>
@ 2011-01-19 20:34 ` Andrew Morton
2011-01-19 21:33 ` David Nicol
0 siblings, 1 reply; 2+ messages in thread
From: Andrew Morton @ 2011-01-19 20:34 UTC (permalink / raw)
To: Shaohua Li
Cc: linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Chris Mason, Christoph Hellwig, Arjan van de Ven, Yan, Zheng,
Wu, Fengguang, linux-api, manpages
On Wed, 19 Jan 2011 09:15:15 +0800
Shaohua Li <shaohua.li@intel.com> 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?
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH v3 0/5]add new ioctls to do metadata readahead in btrfs
2011-01-19 20:34 ` [PATCH v3 0/5]add new ioctls to do metadata readahead in btrfs Andrew Morton
@ 2011-01-19 21:33 ` David Nicol
0 siblings, 0 replies; 2+ messages in thread
From: David Nicol @ 2011-01-19 21:33 UTC (permalink / raw)
To: Andrew Morton
Cc: Shaohua Li, linux-btrfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Chris Mason, Christoph Hellwig,
Arjan van de Ven, Yan, Zheng, Wu, Fengguang, linux-api, manpages
On Wed, Jan 19, 2011 at 2:34 PM, Andrew Morton
<akpm@linux-foundation.org> 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?
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-01-19 21:33 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1295399715.1949.863.camel@sli10-conroe>
2011-01-19 20:34 ` [PATCH v3 0/5]add new ioctls to do metadata readahead in btrfs Andrew Morton
2011-01-19 21:33 ` David Nicol
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).