linux-kernel - Re: [PATCH 1/4] iomap: Lift blocksize restriction on 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: <ca18ef93-2db5-4958-abf1-65d94f1c71a4@oracle.com>
Date: Thu, 23 Jan 2025 09:28:12 +0000
From: John Garry <john.g.garry@...cle.com>
To: Dave Chinner <david@...morbit.com>
Cc: Christoph Hellwig <hch@....de>, "Darrick J. Wong" <djwong@...nel.org>,
        brauner@...nel.org, cem@...nel.org, dchinner@...hat.com,
        ritesh.list@...il.com, linux-xfs@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        martin.petersen@...cle.com
Subject: Re: [PATCH 1/4] iomap: Lift blocksize restriction on atomic writes

On 22/01/2025 23:51, Dave Chinner wrote:
>> I did my own quick PoC to use CoW for misaligned blocks atomic writes
>> fallback.
>>
>> I am finding that the block allocator is often giving misaligned blocks wrt
>> atomic write length, like this:
> Of course - I'm pretty sure this needs force-align to ensure that
> the large allocated extent is aligned to file offset and hardware
> atomic write alignment constraints....
> 
>> Since we are not considering forcealign ATM, can we still consider some
>> other alignment hint to the block allocator? It could be similar to how
>> stripe alignment is handled.
> Perhaps we should finish off the the remaining bits needed to make
> force-align work everywhere before going any further?

forcealign implementation is just about finished from my PoV, but needs 
more review.

However, there has been push back on that feature - 
https://lore.kernel.org/linux-xfs/20240923120715.GA13585@lst.de/

So we will try this PoC for the unaligned software-emulated fallback, 
see how it looks - especially in terms of performance - and go from there.

> 
>> Some other thoughts:
>> - I am not sure what atomic write unit max we would now use.
> What statx exposes should be the size/alignment for hardware offload
> to take place (i.e. no change)

The user could get that from statx on the block device on which we are 
mounted, if that is not too inconvenient.

>, regardless of what the filesystem
> can do software offloads for. i.e. like statx->stx_blksize is the
> "preferred block size for efficient IO", the atomic write unit
> information is the "preferred atomic write size and alignment for
> efficient IO", not the maximum sizes supported...

It's already documented that an atomic write which exceeds the unit max 
will be rejected. I don't like the idea of relaxing the API to "an 
atomic which exceeds unit max may be rejected". Indeed, in that case, 
the user may still want to know the non-optimal unit max.

> 
>> - Anything written back with CoW/exchange range will need FUA to ensure that
>> the write is fully persisted.
> I don't think so. The journal commit for the exchange range
> operation will issue a cache flush before the journal IO is
> submitted. that will make the new data stable before the first
> xchgrange transaction becomes stable.
> 
> Hence we get the correct data/metadata ordering on stable storage
> simply by doing the exchange-range operation at data IO completion.
> This the same data/metadata ordering semantics that unwritten extent
> conversion is based on....

I am not sure if we will use exchange range, but we need such behavior 
(in terms of persistence) described for whatever we do.

Thanks,
John