xfsprogs: aligned file data extent mappings [v2 60/62]

Years ago during the adaptation of XFS to persistent memory, a product
development team expressed a desire to guarantee that mmap mappings of
an S_DAX file on pmem would always get a PMD mapping to increase TLB hit
rates.  That means ensuring that all space allocations are aligned to
2MB (on x86) and ensuring that the file range of each file space mapping
are aligned to 2MB.  Then pmem faded.

NVME/SCSI atomic write unit support has brought this discussion back to
the forefront, because untorn writes to conventional storage only work
if the space allocations are aligned to the max atomic write unit.  To
simplify the administrative model a bit, we want to ensure that the
mappings are aligned to the same value.  IOWs, for a storage device that
supports up to 64k atomic write units, we want to ensure that the file
range of all mappings are aligned to 64k.

From a file metadata perspective, these are nearly the same use case.
The realtime volume already has a realtime extent size field that forces
the alignment of both space and mapping, but not everyone wants to
adminster a realtime volume.  This patchset adds a forcealign superblock
feature and inode flag so that we can impose the same alignment
restrictions on selected files on the data volume.

IOWs, you can now set an inode flag that causes regular files on the
data volume to have rextsize-aligned space mappings.  This is an
improvement over ext4 bigalloc style things that impose the larger
allocation unit size even for things that don't need it.

Note: Currently this patchset reuses sb_rextsize for the forcealign
value because that enabled reuse of the COW around code that I wrote for
realtime reflink that ensures that remapping operations follow
forcealign.

This has been running on the djcloud for months with no problems.  Enjoy!

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQQ2qTKExjcn+O1o2YRKO3ySh0YRpgUCZjBeOgAKCRBKO3ySh0YR
pnMGAP9cFaXCC0Of7E1QHXobkSBRhkfoV+ldYFUHVEGs873zXwD/VDl+h8UrE5st
qCQ/idCxXNV7ECqo3pjWwQnCv/1lyg4=
=D3R0
-----END PGP SIGNATURE-----