* XFS_IOC_FSEMAP (old XFS_IOC_FIEMAPFS) @ 2016-06-01 12:36 Carlos Maiolino 2016-06-02 5:41 ` Darrick J. Wong 0 siblings, 1 reply; 3+ messages in thread From: Carlos Maiolino @ 2016-06-01 12:36 UTC (permalink / raw) To: xfs Howdy folks, I've talked to Dave about moving forward XFS_IOC_FIEMAPFS ioctl, and consequently their users, such as xfs_spaceman tool. For now, I'm porting the old stuff to the current code, doing code cleanups, etc. If someone wants to take a look, I've made the patches available here: https://github.com/cmaiolino/linux/tree/fsemap For now, I just did the port forward of the patches, but still need to clean up a few stuff, and also port forward xfs_spaceman. As per Dave suggestion (as you can see in $SUBJ), the ioctl has been renamed to XFS_IOC_FSEMAP. -- Carlos _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: XFS_IOC_FSEMAP (old XFS_IOC_FIEMAPFS) 2016-06-01 12:36 XFS_IOC_FSEMAP (old XFS_IOC_FIEMAPFS) Carlos Maiolino @ 2016-06-02 5:41 ` Darrick J. Wong 2016-06-02 7:04 ` Dave Chinner 0 siblings, 1 reply; 3+ messages in thread From: Darrick J. Wong @ 2016-06-02 5:41 UTC (permalink / raw) To: xfs, cmaiolino, Dave Chinner On Wed, Jun 01, 2016 at 02:36:50PM +0200, Carlos Maiolino wrote: > Howdy folks, > > I've talked to Dave about moving forward XFS_IOC_FIEMAPFS ioctl, and > consequently their users, such as xfs_spaceman tool. > > For now, I'm porting the old stuff to the current code, doing code cleanups, > etc. > > If someone wants to take a look, I've made the patches available here: > > https://github.com/cmaiolino/linux/tree/fsemap > > For now, I just did the port forward of the patches, but still need to clean up > a few stuff, and also port forward xfs_spaceman. > > As per Dave suggestion (as you can see in $SUBJ), the ioctl has been renamed to > XFS_IOC_FSEMAP. I was planning to push the GETFSMAPX ioctl that we talked about at LSF as part of the reverse mapping patchset: https://lwn.net/Articles/685978/ Patches here: https://github.com/djwong/linux/commit/fa063533cffa4627f423ba952422796da9364cfc https://github.com/djwong/xfsprogs/commit/21502ebb972f03319940fe8bb1a1e6fcb181ed3f https://github.com/djwong/xfsprogs/commit/8347e762e3b94dc14f40754a4db952acdadfb080 https://github.com/djwong/man-pages/commit/822729ce87cb389f5d980d88187d86745e41ecd5 GETFSMAPX reports device id and owner id, which (AFAICT) FSEMAP doesn't. I think the btrfs folks are interested in using the (possibly obsolete) mappings for duperemove enhancements, and from the brief look I took at spaceman, it could use this interface for its reporting. xfs_scrub could (possibly) use it to figure out which parts of the disk to scrub. I think it'd be pretty simple to bring spaceman up to date with current xfsprogs and teach it to use GETFSMAPX. I also think there could be a (stupider) GETFSMAPX implementation for non-rmapbt filesystems that only reports free space extents that are in the bnobt. --D > > -- > Carlos > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: XFS_IOC_FSEMAP (old XFS_IOC_FIEMAPFS) 2016-06-02 5:41 ` Darrick J. Wong @ 2016-06-02 7:04 ` Dave Chinner 0 siblings, 0 replies; 3+ messages in thread From: Dave Chinner @ 2016-06-02 7:04 UTC (permalink / raw) To: Darrick J. Wong; +Cc: cmaiolino, xfs On Wed, Jun 01, 2016 at 10:41:51PM -0700, Darrick J. Wong wrote: > On Wed, Jun 01, 2016 at 02:36:50PM +0200, Carlos Maiolino wrote: > > Howdy folks, > > > > I've talked to Dave about moving forward XFS_IOC_FIEMAPFS ioctl, and > > consequently their users, such as xfs_spaceman tool. > > > > For now, I'm porting the old stuff to the current code, doing code cleanups, > > etc. > > > > If someone wants to take a look, I've made the patches available here: > > > > https://github.com/cmaiolino/linux/tree/fsemap > > > > For now, I just did the port forward of the patches, but still need to clean up > > a few stuff, and also port forward xfs_spaceman. > > > > As per Dave suggestion (as you can see in $SUBJ), the ioctl has been renamed to > > XFS_IOC_FSEMAP. > > I was planning to push the GETFSMAPX ioctl that we talked about at LSF > as part of the reverse mapping patchset: > > https://lwn.net/Articles/685978/ > > Patches here: > > https://github.com/djwong/linux/commit/fa063533cffa4627f423ba952422796da9364cfc > https://github.com/djwong/xfsprogs/commit/21502ebb972f03319940fe8bb1a1e6fcb181ed3f > https://github.com/djwong/xfsprogs/commit/8347e762e3b94dc14f40754a4db952acdadfb080 > https://github.com/djwong/man-pages/commit/822729ce87cb389f5d980d88187d86745e41ecd5 > > GETFSMAPX reports device id and owner id, which (AFAICT) FSEMAP > doesn't. I think the btrfs folks are interested in using the > (possibly obsolete) mappings for duperemove enhancements, and from the > brief look I took at spaceman, it could use this interface for its > reporting. xfs_scrub could (possibly) use it to figure out which > parts of the disk to scrub. GETFSMAP is a bit different to FSEMAP. fsemap is for iterating things like free space extents for generating histograms or determining if free space is fragmented in a quick, concise manner. I can see how you could do this with GETFSMAP, but it seems a lot less efficient to get this infomration from the rmap tree rather than directly from the free space trees. Indeed, I see that FSEMAP is similar to XFS_IOC_FSINUMBERS in that it returns a specific set of information that could then be used to quickly target ranges of the filesystem with GETFSMAP. e.g. freespace defragmentation requires us to first identify an area of fragmented space to address, GETFSMAP() on the used space in that range then tells us the owners of the objects we need to move to defragment that free space... Hence I see them as complementary rather than competing interfaces, and it not being a problem to introduce two separate interfaces to extract all this info... > I think it'd be pretty simple to bring spaceman up to date with > current xfsprogs and teach it to use GETFSMAPX. Should be no harder than adding ti to xfs_io - spaceman is structured almost identically to xfs_io. > I also think there > could be a (stupider) GETFSMAPX implementation for non-rmapbt > filesystems that only reports free space extents that are in the > bnobt. Which is what FSEMAP already does. No need to implement GETFSMAPX twice for different filesystem formats... :P Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-06-02 7:04 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-06-01 12:36 XFS_IOC_FSEMAP (old XFS_IOC_FIEMAPFS) Carlos Maiolino 2016-06-02 5:41 ` Darrick J. Wong 2016-06-02 7:04 ` Dave Chinner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox