From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id B23F57F37 for ; Thu, 24 Oct 2013 16:31:22 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 9AE868F8054 for ; Thu, 24 Oct 2013 14:31:22 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id H9cZnaDzKYgMUWyC for ; Thu, 24 Oct 2013 14:31:20 -0700 (PDT) Date: Fri, 25 Oct 2013 08:31:17 +1100 From: Dave Chinner Subject: Re: [PATCH 13/19] xfs: vectorise directory data operations Message-ID: <20131024213117.GX2797@dastard> References: <1381789085-21923-1-git-send-email-david@fromorbit.com> <1381789085-21923-14-git-send-email-david@fromorbit.com> <20131024183909.GV1935@sgi.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20131024183909.GV1935@sgi.com> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Ben Myers Cc: xfs@oss.sgi.com On Thu, Oct 24, 2013 at 01:39:09PM -0500, Ben Myers wrote: > On Tue, Oct 15, 2013 at 09:17:59AM +1100, Dave Chinner wrote: > > From: Dave Chinner > > > > Following from the initial patches to vectorise the shortform > > directory encode/decode operations, convert half the data block > > operations to use the vector. The rest will be done in a second > > patch. > > > > This further reduces the size of the built binary: > > > > text data bss dec hex filename > > 794490 96802 1096 892388 d9de4 fs/xfs/xfs.o.orig > > 792986 96802 1096 890884 d9804 fs/xfs/xfs.o.p1 > > 792350 96802 1096 890248 d9588 fs/xfs/xfs.o.p2 > > 789293 96802 1096 887191 d8997 fs/xfs/xfs.o.p3 > > > > Signed-off-by: Dave Chinner > > Reviewed-by: Christoph Hellwig > > Generally looks pretty good, I have a question below... > > > const struct xfs_dir_ops xfs_dir2_ftype_ops = { > > @@ -223,6 +415,18 @@ const struct xfs_dir_ops xfs_dir2_ftype_ops = { > > .sf_put_ino = xfs_dir3_sfe_put_ino, > > .sf_get_parent_ino = xfs_dir2_sf_get_parent_ino, > > .sf_put_parent_ino = xfs_dir2_sf_put_parent_ino, > > + > > + .data_entsize = xfs_dir3_data_entsize, > > + .data_get_ftype = xfs_dir3_data_get_ftype, > > + .data_put_ftype = xfs_dir3_data_put_ftype, > > + .data_entry_tag_p = xfs_dir3_data_entry_tag_p, > > + > > + .data_dot_offset = xfs_dir2_data_dot_offset, > > + .data_dotdot_offset = xfs_dir2_data_dotdot_offset, > > + .data_first_offset = xfs_dir2_data_first_offset, > > + .data_dot_entry_p = xfs_dir2_data_dot_entry_p, > > + .data_dotdot_entry_p = xfs_dir2_data_dotdot_entry_p, > > + .data_first_entry_p = xfs_dir2_data_first_entry_p, > > }; > > I think there may be a problem here. Although the dirv2 functions for > ., .., and first entry offset account for the v2 header size, they > appear not to be accounting for the modified entry size due to the file > type field. Am I missing something? The ftype field is handled by the alignment roundup. i.e. namelen is 1 or two bytes, plus ftype is 2 or 3 bytes, roundup is to 8 bytes. Hence adding a byte for the ftype field is not a problem for these first entries because of their small, fixed size. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs