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: <93eecf38-272b-426f-96ec-21939cd3fbc5@oracle.com>
Date: Wed, 18 Dec 2024 11:15:42 +0000
From: John Garry <john.g.garry@...cle.com>
To: Christoph Hellwig <hch@....de>, "Darrick J. Wong" <djwong@...nel.org>
Cc: 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 v2 2/7] iomap: Add zero unwritten mappings dio support

On 17/12/2024 07:08, Christoph Hellwig wrote:
> On Fri, Dec 13, 2024 at 04:56:38PM -0800, Darrick J. Wong wrote:
>>>> "If you receive -EBADMAP, then call fallocate(FALLOC_FL_MAKE_OVERWRITE)
>>>> to force all the mappings to pure overwrites."
>>>
>>> Ewwwwwwwwwwwwwwwwwwwww.
>>>
>>> That's not a sane API in any way.
>>
>> Oh I know, I'd much rather stick to the view that block untorn writes
>> are a means for programs that only ever do IO in large(ish) blocks to
>> take advantage of a hardware feature that also wants those large
>> blocks.
> 
> I (vaguely) agree ith that.
> 
>> And only if the file mapping is in the correct state, and the
>> program is willing to *maintain* them in the correct state to get the
>> better performance.
> 
> I kinda agree with that, but the maintain is a bit hard as general
> rule of thumb as file mappings can change behind the applications
> back.  So building interfaces around the concept that there are
> entirely stable mappings seems like a bad idea.

I tend to agree.

> 
>> I don't want xfs to grow code to write zeroes to
>> mapped blocks just so it can then write-untorn to the same blocks.
> 
> Agreed.
> 

So if we want to allow large writes over mixed extents, how to handle?

Note that some time ago we also discussed that we don't want to have a 
single bio covering mixed extents as we cannot atomically convert all 
unwritten extents to mapped.

Thanks,
John




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ