XFS_IOC_FSEMAP (old XFS_IOC_FIEMAPFS)
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.
Signature · 6 lines
Carlos _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Carlos Maiolino
Howdy folks,
I've talked to Dave about moving forward
XFS_IOC_FIEMAPFSioctl, and consequently their users, such asxfs_spacemantool.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:
Quoted 7 lines
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
Quoted 8 lines
Signature · 7 lines
-- Carlos _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 31 lines · Darrick J. Wong
Quoted 10 lines · Carlos Maiolino
Howdy folks,
I've talked to Dave about moving forward
XFS_IOC_FIEMAPFSioctl, and consequently their users, such asxfs_spacemantool.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:
Quoted 7 lines
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
Quoted 6 lines
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_scrubcould (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...
Quoted 2 lines
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.
Quoted 4 lines
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.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs