[Cluster-devel] [PATCH 1/2] gfs2: Extended attribute readahead

[Steven Whitehouse <swhiteho@redhat.com>]

Hi,

On 03/11/15 17:29, Bob Peterson wrote:
> ----- Original Message -----
>> When gfs2 allocates an inode and its extended attribute block next to
>> each other at inode create time, the inode's directory entry indicates
>> that in de_rahead.  In that case, we can readahead the extended
>> attribute block when we read in the inode.
>>
>> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
>> ---
>>   fs/gfs2/dir.c     | 15 +++++++++++----
>>   fs/gfs2/incore.h  |  1 +
>>   fs/gfs2/meta_io.c | 27 +++++++++++++++++++++++++--
>>   fs/gfs2/meta_io.h |  2 +-
>>   fs/gfs2/quota.c   |  2 +-
>>   fs/gfs2/rgrp.c    |  2 +-
>>   fs/gfs2/super.c   |  1 +
>>   fs/gfs2/xattr.c   | 10 +++++-----
>>   8 files changed, 46 insertions(+), 14 deletions(-)
>>
> Hi Andreas,
>
> Most of this looks good. However, two comments:
>
> 1. I don't like adding a new u16 to the gfs2_inode. I've been working to
>     reduce the size of gfs2's inodes lately, so I'd rather see this
>     implemented as a new GIF_RAHEAD (or similar) flag in gfs2_inode's i_flags.
> 2. It seems to me like we should take advantage of function gfs2_meta_ra()
>     which already submits one block and a variable number of additional
>     blocks for read-ahead, then waits for the first block IO to complete.
The meta_ra thing is a bit of a hack, and best avoided for this use. We 
want to only send out a single I/O here rather than let the I/O stack do 
the merging after the fact,

Steve.

> Regards,
>
> Bob Peterson
> Red Hat File Systems