Re: [PATCH v3 0/5]add new ioctls to do metadata readahead in btrfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2011-01-20 at 04:34 +0800, Andrew Morton wrote:
> On Wed, 19 Jan 2011 09:15:15 +0800
> Shaohua Li <shaohua.li@xxxxxxxxx> 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?
Not yet. I do expect ext4 guys can check it. From my understanding, it
should be relatively easy to do it in ext filesystems.

> >   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?
a laptop/desktop/server need read more data from hard disks, this will
give more bootup time saving I think, though not tested yet.

> 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?
Currently most popular netbooks are using rotating disks actually. And
this will benefit laptop/desktop too.

Thanks,
Shaohua

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux