xfs
[Top] [All Lists]

Re: [PATCH 18/18] xfs: add xfs_da_geometry to inode forks

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 18/18] xfs: add xfs_da_geometry to inode forks
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Fri, 9 May 2014 00:31:27 -0700
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1399537188-26509-19-git-send-email-david@xxxxxxxxxxxxx>
References: <1399537188-26509-1-git-send-email-david@xxxxxxxxxxxxx> <1399537188-26509-19-git-send-email-david@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, May 08, 2014 at 06:19:48PM +1000, Dave Chinner wrote:
> While this might seem wasteful to burn a pointer in the data fork
> for all files, consider that the geometry information
> for data allocation can be abstracted from the xfs_mount in exactly
> the same way as has been done for the directory geometry.
> Effectively it's a hook to carry allocation policy around in....
> 
> So, add the geometry pointer to the inode fork, and initialise is
> appropriately and use it for all the directory and attribute
> operation setup instead ofthe xfs_mount version.

A definitively NAK to bloating the inode without actually making
use of this.  I can see where you might want to go with this, but
until we actuall support different dir block sizes per inodes or
similar, and it actually proves to be useful this is not something
that should go in.

The rest of the series looks okay as long as we don't touch the inode,
but I'll have to do a slightly more detailed review.

<Prev in Thread] Current Thread [Next in Thread>