From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Tue, 3 Nov 2015 19:02:51 +0000 Subject: [Cluster-devel] [PATCH 1/2] gfs2: Extended attribute readahead In-Reply-To: <1797651004.2591857.1446571755023.JavaMail.zimbra@redhat.com> References: <1446404579-5211-1-git-send-email-agruenba@redhat.com> <1446404579-5211-2-git-send-email-agruenba@redhat.com> <1797651004.2591857.1446571755023.JavaMail.zimbra@redhat.com> Message-ID: <563904DB.6020900@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 >> --- >> 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