On Tue, Jul 29, 2014 at 10:26:50AM +1000, Dave Chinner wrote: > On Mon, Jul 28, 2014 at 08:14:01AM -0400, Brian Foster wrote: > > On Sat, Jul 26, 2014 at 10:03:35AM +1000, Dave Chinner wrote: > > > On Fri, Jul 25, 2014 at 12:30:57PM -0400, Brian Foster wrote: > > > > Hmm, I suppose that does create a new and interesting dynamic with > > > > regard to the feature bit (non-deterministic backwards compatibility). > > > > One could certainly value backwards compatibility over this particular > > > > feature, and there is currently no way to control it. I'll look into > > > > doing something with xfs_admin. In fact, I was thinking of adding > > > > something to tune the cluster size bit to get around the v5 scaling > > > > issue anyways. > > > > > > What v5 scalability issue is that? I don't recall any outstanding > > > issues with inode cluster IO.... > > > > > > > There's no scalability issue... I'm just referring to the fact that we > > scale the cluster size by the inode size increase factor on v5 > > superblocks. > > > > E.g., my free space fragmentation xfstests test started out with a fixed > > file size based on something close to the worst case with an > > implementation that used the allocation granularity of max(<holemask bit > > granularity>, <inodes per block>). Once I tied the implementation to the > > cluster size due to the aforementioned complexities, it became apparent > > the test was less effective with my chosen file size on v5 supers, > > particularly as the inode size increased. So from there I was > > considering a similar xfs_admin command a user could run to reduce the > > cluster size as a backstop should this limitation arise in the real > > world. We can start with doing something just to enable the feature as > > outlined above and revisit this then... > > Right, but I'd suggest that the better long term solution to avoid > the limitations of inode cluster buffer alignment issues is to get > rid of inode clusters and inode buffers altogether. We only need > inode buffers for logging unlinked list modifications, so once we > log those as part of the inode core for for v5 filesystems then we > can do much more dynamic inode IO. That then frees us up to do fine > grained sparse inode allocation because we aren't limited by > in-memory buffering limitations. > > http://xfs.org/index.php/Improving_inode_Caching#Food_For_Thought_.28Crazy_Ideas.29 > Interesting, thanks. I guess removing the need for the code that's incompatible with the sub-cluster size granularity is a nice option. :) I'll have to read into this some more once the basic sparse inode feature is more hashed out. Brian > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
