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 <agrue...@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
