lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 02 Feb 2017 15:50:05 -0800
From:   "Darrick J. Wong" <>
Subject: [RFC PATCH 0/2] ext4: GETFSMAP support

Hi all,

Here's an RFC patchset that partially implements the GETFSMAP ioctl on
ext4.  Because ext4 does not have reverse-mapping data, it uses the same
fallback as XFS does when there's no rmapbt -- we report fixed-location
metadata and the free extents listed in the block bitmaps, then fill in
the rest with "owner unknown".

Yes, this the same GETFSMAP ioctl that we discussed at LSFMM[1] that has
been banging around in my XFS tree[2] for months.

The second patch implements a semi-clone of the XFS FSGEOMETRY ioctl.
The structure that ext4 returns is set up to mirror the XFS structure
where there's overlap.  The magic numbers of the ext4 ioctl are
different to prevent old XFS tools from falling in by accident, though
the intent is to ease adapting of the GETFSMAP xfs tools (xfs_io and
xfs_spaceman) for ext4.

My plan is to hoist the common GETFSMAP definitions (the structure, the
flags, and none of the special owner codes) to the VFS prior to
combining this patchset with its XFS counterpart.  Note: The special
owner codes (FMR_OWN_*) are filesystem specific and will never be
hoisted to the VFS headers in their current form.  However, I thought it
might be useful to push this to the ext4 list for some early review. 

If you want to play with this, I recommend pulling my latest xfsprogs
code from git[3] so that xfs_spaceman and xfs_io work on ext4.

Questions?  Comments?



Powered by blists - more mailing lists