XFS_IOC_FSEMAP (old XFS_IOC_FIEMAPFS)

XFS_IOC_FSEMAP (old XFS_IOC_FIEMAPFS)

[Carlos Maiolino]

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

Re: XFS_IOC_FSEMAP (old XFS_IOC_FIEMAPFS)

[Darrick J. Wong]

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

Re: XFS_IOC_FSEMAP (old XFS_IOC_FIEMAPFS)

[Dave Chinner]

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