linux-ext4 - Re: [LSF/MM/BPF TOPIC] extsize and forcealign design in filesystems for atomic writes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z6eO3k4SG6TIA12p@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>
Date: Sat, 8 Feb 2025 22:35:34 +0530
From: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
To: John Garry <john.g.garry@...cle.com>
Cc: lsf-pc@...ts.linux-foundation.org, linux-xfs@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, djwong@...nel.org, dchinner@...hat.com,
        hch@....de, ritesh.list@...il.com, jack@...e.cz, tytso@....edu,
        linux-ext4@...r.kernel.org
Subject: Re: [LSF/MM/BPF TOPIC] extsize and forcealign design in filesystems
 for atomic writes

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@gmail.com/ 
> 
> 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@oracle.com/ 
> > > 
> > > 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