On Fri, Feb 07, 2025 at 12:01:32PM +0000, John Garry wrote: > > > Yes, bigalloc is indeed good enough as a start but yes eventually > > something like forcealign will be beneficial as not everyone prefers an > > FS-wide cluster-size allocation granularity. > > > > We do have a patch for atomic writes with bigalloc that was sent way > > back in mid 2024 but then we went into the same discussion of mixed > > mapping[1]. > > > > Hmm I think it might be time to revisit that and see if we can do > > something better there. > > > > [1] https://lore.kernel.org/linux-ext4/37baa9f4c6c2994df7383d8b719078a527e521b9.1729825985.git.ritesh.list@xxxxxxxxx/ > > Feel free to pick up the iomap patches I had for zeroing when trying to > atomic write mixed mappings - that's in my v3 series IIRC. Thanks I'll give it a try. > > But you might still get some push back on them... Right, it would be good if we all can come to a consensus of what to do if an FS wants to implement something like forcealign for atomic writes but does not have a way to implement software fallback. As I see, we seem to be 2 (un)popular options: 1. Reject atomic writes on mixed mappings. This is not user space friendly but simplest to implement 2. Zero out the unwritten part of the mapping and convert to a single mapping before performing the IO. All options have their shortcomings but I think 2 is still okay. I believe thats the path we've taken in the latest XFS patches right. > > > > > > > > > > > > > > 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. > > > > True, but it's something that just implicitly happens when we use > > forcealign. I eventually found out while testing forcealign with > > different operations but such things can come as a surprise to users > > especially when we support some operations to be unaligned and then > > reject some other similar ones. > > > > punch_hole/collapse_range is just an example and yes it might not be > > very important to support unaligned collapse range but in the long run > > it would be good to have these things documented/discussed. > > Maybe the man pages can be documented for forcealign/rtextsize > 1 punch > holes/collapse behaviour - at a quick glance, I could not see anything. Yep sounds good. > Indeed, I am not sure how bigalloc affects punch holes/collapse range > either. Yeah, I think even bigalloc has the similar behavior of disallowing unaligned insert/collapse ranges but allowing punch hole. > > Thanks, > John Regards, ojaswin
