On Mon, Jun 01, 2015 at 10:12:30AM +1000, Dave Chinner wrote: > On Thu, Feb 19, 2015 at 02:10:34PM -0500, Brian Foster wrote: > > On Thu, Feb 19, 2015 at 01:13:25PM -0500, Brian Foster wrote: > > > Hi all, > > > > > > Here's v5 of sparse inode chunks. The only real change here is to > > > convert the allocmask helpers back to using the XFS bitmap helpers > > > rather than the generic bitmap code. This eliminates the need for the > > > endian-conversion hack and extra helper to export a generic bitmap to a > > > native type. The former users of the generic bitmap itself have been > > > converted to use the native 64-bit value appropriately. > > > > > > The XFS bitmap code is actually not in userspace either so neither of > > > these implementations backport cleanly to userspace. As it is, I've not > > > included the sparse alloc/free code in my xfsprogs branch as this code > > > currently isn't needed. Nothing in userspace that I've seen requires the > > > ability to do a sparse inode allocation or free. I suspect if it is > > > needed in the future, we can more easily sync the XFS bitmap helpers to > > > userspace than the generic Linux bitmap code. > > > > > > Thoughts, reviews, flames appreciated... > > > > > > > Attached is a tarball of a set of xfsprogs patches to aid in testing > > this patchset. I'm posting as a tarball because the core patches (e.g., > > the kernel patches) are obviously still in flux. The tarball includes > > the following: > > > > - general dependency backports > > - core infrastructure backports (i.e., applicable patches from this v5 > > sparse inode set) > > - xfsprogs work for sparse inode support > > > > The latter bits include support for mkfs, xfs_info, xfs_db and > > xfs_repair, the fundamentals of all of which should work. Use the '-i > > spalign' mkfs option to format a sparse inode enabled fs. E.g.: > > > > mkfs.xfs -m crc=1,finobt=1 -i spalign <dev> > > > > Note that metadump is not yet supported. Failures from the associated > > xfstests, etc. are expected. I'm not aware of anything else that is > > missing support or otherwise broken, so any feedback along those lines > > is appreciated. > > Notes: > > - mkfs output doesn't indicate that sparse inodes are configured. > - mkfs cli option of "-i sparse=[0|1]" makes more sense than > "spalign" > - "SPARSE_INODES" missing from xfs_db version output Ok... > - kernel code seems to be regression from when not using sparse > inodes What regression are you referring to? > - inode allocation speed does not seem to be impacted by sparse > inode allocation - running my fsmark tests on a debug kernel show > no performance differential, even though sparse inode chunks > should be created in that case. > - it smoke tests through xfstests ok > I haven't really run into much for issues so far save for a problem discovered with the DEBUG mode code from my recent large block size testing. I have a patch for that lying around I need to post... > I haven't really looked through the userspace code in any detail, > so I can't really comment on that side of things yet. The kernel > code looks good, there doesn't appear to be any regressions and the > new functionailty works so far. Hence I think I'm going to merge > the kernel code in the 4.2 cycle, and we can work on getting > userspace into the current dev tree for people to test and use the > new code.... > Sounds good, thanks. The userspace bits have only been posted for testing purposes to this point to avoid the churn from active review of the core code. Since that is now merged, I'll get the latest mechanism ported over to userspace, incorporate some of the fixes noted above and get something posted hopefully soon. 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
