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] [thread-next>] [day] [month] [year] [list]
Message-ID: <f4d2180a-8baa-4636-a0a1-36e474fcd157@oracle.com>
Date: Fri, 4 Oct 2024 14:07:05 +0100
From: John Garry <john.g.garry@...cle.com>
To: Christoph Hellwig <hch@....de>
Cc: axboe@...nel.dk, brauner@...nel.org, djwong@...nel.org,
        viro@...iv.linux.org.uk, jack@...e.cz, dchinner@...hat.com,
        cem@...nel.org, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-xfs@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, hare@...e.de,
        martin.petersen@...cle.com, catherine.hoang@...cle.com,
        mcgrof@...nel.org, ritesh.list@...il.com, ojaswin@...ux.ibm.com
Subject: Re: [PATCH v7 5/8] xfs: Support FS_XFLAG_ATOMICWRITES

On 04/10/2024 13:35, Christoph Hellwig wrote:
> On Fri, Oct 04, 2024 at 09:22:51AM +0000, John Garry wrote:
>> Add initial support for new flag FS_XFLAG_ATOMICWRITES.
>>
>> This flag is a file attribute that mirrors an ondisk inode flag.  Actual
>> support for untorn file writes (for now) depends on both the iflag and the
>> underlying storage devices, which we can only really check at statx and
>> pwritev2() time.  This is the same story as FS_XFLAG_DAX, which signals to
>> the fs that we should try to enable the fsdax IO path on the file (instead
>> of the regular page cache), but applications have to query STAT_ATTR_DAX to
>> find out if they really got that IO path.
>>
>> Current kernel support for atomic writes is based on HW support (for atomic
>> writes). Since for regular files XFS has no way to specify extent alignment
>> or granularity, atomic write size is limited to the FS block size.
> 
> I'm still confused why this flag is needed for the current version
> of this patch set. 


> We should always be able to support atomic writes
> <= block size if support by the block device.
> 

Sure, that is true (about being able to atomically write 1x FS block if 
the bdev support it).

But if we are going to add forcealign or similar later, then it would 
make sense (to me) to have FS_XFLAG_ATOMICWRITES (and its other flags) 
from the beginning. I mean, for example, if FS_XFLAG_FORCEALIGN were 
enabled and we want atomic writes, setting FS_XFLAG_ATOMICWRITES would 
be rejected if AG count is not aligned with extsize, or extsize is not a 
power-of-2, or extsize exceeds bdev limits. So FS_XFLAG_ATOMICWRITES 
could have some value there.

As such, it makes sense to have a consistent user experience and require 
FS_XFLAG_ATOMICWRITES from the beginning.

Cheers,
John

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ