| Message ID | 20240705162450.3481169-1-john.g.garry@oracle.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | forcealign for xfs | expand |
On Fri, Jul 05, 2024 at 04:24:37PM +0000, John Garry wrote: > The actual forcealign patches are the same in this series, modulo an > attempt for a fix in xfs_bunmapi_align(). > > Why forcealign? > In some scenarios to may be required to guarantee extent alignment and > granularity. > > For example, for atomic writes, the maximum atomic write unit size would > be limited at the extent alignment and granularity, guaranteeing that an > atomic write would not span data present in multiple extents. > > forcealign may be useful as a performance tuning optimization in other > scenarios. From previous side discussion I know Dave disagrees, but given how much pain the larger than FSB rtextents have caused I'm very skeptical if taking this on is the right tradeoff.
On 06/07/2024 08:53, Christoph Hellwig wrote: > On Fri, Jul 05, 2024 at 04:24:37PM +0000, John Garry wrote: >> The actual forcealign patches are the same in this series, modulo an >> attempt for a fix in xfs_bunmapi_align(). >> >> Why forcealign? >> In some scenarios to may be required to guarantee extent alignment and >> granularity. >> >> For example, for atomic writes, the maximum atomic write unit size would >> be limited at the extent alignment and granularity, guaranteeing that an >> atomic write would not span data present in multiple extents. >> >> forcealign may be useful as a performance tuning optimization in other >> scenarios. > > From previous side discussion I know Dave disagrees, but given how > much pain the larger than FSB rtextents have caused I'm very skeptical > if taking this on is the right tradeoff. > I am not sure what that pain is, but I guess it's the maintainability and scalability of the scattered "if RT" checks for rounding up and down to larger extent size, right? For forcealign, at least we can factor that stuff mostly into common forcealign+RT helpers, to keep the checks common. That is apart from the block allocator code. >
On Mon, Jul 08, 2024 at 08:48:19AM +0100, John Garry wrote: > I am not sure what that pain is, but I guess it's the maintainability and > scalability of the scattered "if RT" checks for rounding up and down to > larger extent size, right? > > For forcealign, at least we can factor that stuff mostly into common > forcealign+RT helpers, to keep the checks common. That is apart from the > block allocator code. Maybe its just me hating all the rtalloc larger than block size allocation granularity mess and hoping it goes away. With this we'll make it certain that it is not going away, but that might just have been a faint hope. But if we add more of it we'll at least need to ensure it is done using common helpers and clean the existing mess up as much as we can.
This series is being spun off the block atomic writes for xfs series at [0]. That series has got too big and also has a dependency on the core block atomic writes support, which has now been queued for 6.11 in Jens' block tree [1]. The actual forcealign patches are the same in this series, modulo an attempt for a fix in xfs_bunmapi_align(). Why forcealign? In some scenarios to may be required to guarantee extent alignment and granularity. For example, for atomic writes, the maximum atomic write unit size would be limited at the extent alignment and granularity, guaranteeing that an atomic write would not span data present in multiple extents. forcealign may be useful as a performance tuning optimization in other scenarios. Early development xfsprogs support is at: https://github.com/johnpgarry/xfsprogs-dev/commits/atomic-writes/ Differences to v1: - Add Darricks RB tags (thanks) - Disallow mount for forcealign and RT - Disallow cp --reflink from forcealign inode - Comments improvements (Darrick) - Coding style improvements (Darrick) - Fix xfs_inode_alloc_unitsize() (Darrick) Baseline: xfs/for-next @ 3ba3ab1f6719 ("xfs: enable FITRIM on the realtime device") [0] https://lore.kernel.org/linux-xfs/20240607143919.2622319-1-john.g.garry@oracle.com/ [1] https://lore.kernel.org/linux-block/20240620125359.2684798-1-john.g.garry@oracle.com/ Darrick J. Wong (2): xfs: Introduce FORCEALIGN inode flag xfs: Enable file data forcealign feature Dave Chinner (6): xfs: only allow minlen allocations when near ENOSPC xfs: always tail align maxlen allocations xfs: simplify extent allocation alignment xfs: make EOF allocation simpler xfs: introduce forced allocation alignment xfs: align args->minlen for forced allocation alignment John Garry (5): xfs: Do not free EOF blocks for forcealign xfs: Update xfs_inode_alloc_unitsize() for forcealign xfs: Unmap blocks according to forcealign xfs: Only free full extents for forcealign xfs: Don't revert allocated offset for forcealign fs/xfs/libxfs/xfs_alloc.c | 33 ++-- fs/xfs/libxfs/xfs_alloc.h | 3 +- fs/xfs/libxfs/xfs_bmap.c | 321 +++++++++++++++++++--------------- fs/xfs/libxfs/xfs_format.h | 9 +- fs/xfs/libxfs/xfs_ialloc.c | 12 +- fs/xfs/libxfs/xfs_inode_buf.c | 55 ++++++ fs/xfs/libxfs/xfs_inode_buf.h | 3 + fs/xfs/libxfs/xfs_sb.c | 2 + fs/xfs/xfs_bmap_util.c | 14 +- fs/xfs/xfs_inode.c | 17 +- fs/xfs/xfs_inode.h | 23 +++ fs/xfs/xfs_ioctl.c | 51 +++++- fs/xfs/xfs_mount.h | 2 + fs/xfs/xfs_reflink.c | 5 +- fs/xfs/xfs_reflink.h | 10 -- fs/xfs/xfs_super.c | 11 ++ fs/xfs/xfs_trace.h | 8 +- include/uapi/linux/fs.h | 2 + 18 files changed, 392 insertions(+), 189 deletions(-)