From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Peterson Date: Tue, 3 Nov 2015 12:29:15 -0500 (EST) Subject: [Cluster-devel] [PATCH 1/2] gfs2: Extended attribute readahead In-Reply-To: <1446404579-5211-2-git-send-email-agruenba@redhat.com> References: <1446404579-5211-1-git-send-email-agruenba@redhat.com> <1446404579-5211-2-git-send-email-agruenba@redhat.com> Message-ID: <1797651004.2591857.1446571755023.JavaMail.zimbra@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ----- 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. Regards, Bob Peterson Red Hat File Systems