1. As I understand XFS untorn atomic write support is built on top
of FORCEALIGN feature (which this series is adding) which in turn
uses extsize hint feature underneath.
Yes.
Now extsize hint mainly controls the alignment of both
"physical start" & "logical start" offset and extent length,
correct?
Yes.
To be clear, only for atomic writes do we require physical block alignment.
This is done using args->alignment for start aand
args->prod/mode variables for extent length. Correct?
Yes.
- If say we are not able to allocate an aligned physical start?
Then since extsize is just a hint we go ahead with whatever
best available extent is right?
---
- Does the unmapping of extents also only happens in extsize
chunks (with forcealign)?
Yes, via use of xfs_inode_alloc_unitsize() in the high level code
aligning the fsbno ranges to be unmapped.
Remember, force align requires both logical file offset and
physical block number to be correctly aligned, so unmap alignment
has to be set up correctly at file offset level before we even know
what extents underly the file range we need to unmap....
If the start or end of the extent which needs unmapping is
unaligned then we convert that extent to unwritten and skip,
is it? (__xfs_bunmapi())
The high level code should be aligning the start and end of the
file range to be removed via xfs_inode_alloc_unitsize().
Is that the case for something like truncate? There we just say what is
the end block which we want to truncate to in
xfs_itruncate_extents_flags(new_size) ->
xfs_bunmapi_range(XFS_B_TO_FSB(new_size)), and that may not be alloc
unit aligned.
Hence
the low level __xfs_bunmapi() code shouldn't ever be encountering
unaligned unmaps on force-aligned inodes.
