On Tue, Feb 04, 2025 at 12:20:25PM +0000, John Garry wrote: > On 01/02/2025 07:12, Ojaswin Mujoo wrote: > > Hi Ojaswin, > > > > For my test case, I am trying 16K atomic writes with 4K FS block size, so I > > > expect the software fallback to not kick in often after running the system > > > for a while (as eventually we will get an aligned allocations). I am > > > concerned of prospect of heavily fragmented files, though. > > Yes that's true, if the FS is up long enough there is bound to be > > fragmentation eventually which might make it harder for extsize to > > get the blocks. > > > > With software fallback, there's again the point that many FSes will need > > some sort of COW/exchange_range support before they can support anything > > like that. > > > > Although I;ve not looked at what it will take to add that to > > ext4 but I'm assuming it will not be trivial at all. > > Sure, but then again you may not have issues with getting forcealign support > accepted for ext4. However, I would have thought that bigalloc was good > enough to use initially. > > > > > > > I agree that forcealign is not the only way we can have atomic writes > > > > work but I do feel there is value in having forcealign for FSes and > > > > hence we should have a discussion around it so we can get the interface > > > > right. > > > > > > > I thought that the interface for forcealign according to the candidate xfs > > > implementation was quite straightforward. no? > > As mentioned in the original proposal, there are still a open problems > > around extsize and forcealign. > > > > - The allocation and deallocation semantics are not completely clear to > > me for example we allow operations like unaligned punch_hole but not > > unaligned insert and collapse range, and I couldn't see that > > documented anywhere. > > For xfs, we were imposing the same restrictions as which we have for > rtextsize > 1. > > If you check the following: > https://lore.kernel.org/linux-xfs/20240813163638.3751939-9-john.g.garry@xxxxxxxxxx/ > > You can see how the large allocunit value is affected by forcealign, and > then check callers of xfs_is_falloc_aligned() -> xfs_inode_alloc_unitsize() > to see how this affects some fallocate modes. > > > > > - There are challenges in extsize with delayed allocation as well as how > > the tooling should handle forcealigned inodes. > > Yeah, maybe. I was only testing my xfs forcealign solution for dio (and no > delayed alloc). XFS turns off delalloc when extsize hints are set. See xfs_buffered_write_iomap_begin() - it starts with: /* we can't use delayed allocations when using extent size hints */ if (xfs_get_extsz_hint(ip)) return xfs_direct_write_iomap_begin(inode, offset, count, flags, iomap, srcmap); and so it treats the allocation like a direct IO write and so force-align should work with buffered writes as expected. This delalloc constraint is a historic relic in XFS - now that we use unwritten extents for delalloc we -could- use delalloc with extsize hints; it just requires the delalloc extents to be aligned to extsize hints. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
