Received-SPF: pass (google.com: domain of linux-ext4+bounces-1568-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Fri, 08 Mar 2024 13:32:36 +0530
Message-Id: <87ttlhp2w3.fsf@doe.com>
From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, Ojaswin Mujoo <ojaswin@linux.ibm.com>, Jan Kara <jack@suse.cz>, Theodore Ts'o <tytso@mit.edu>, Matthew Wilcox <willy@infradead.org>, "Darrick J . Wong" <djwong@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>, John Garry <john.g.garry@oracle.com>, linux-kernel@vger.kernel.org
Subject: Re: [RFC 6/8] ext4: Add an inode flag for atomic writes
In-Reply-To: <ZeYwavaG5WOJTFQ7@dread.disaster.area>
Precedence: bulk

Dave Chinner <david@fromorbit.com> writes:

> On Sat, Mar 02, 2024 at 01:12:03PM +0530, Ritesh Harjani (IBM) wrote:
>> This patch adds an inode atomic writes flag to ext4
>> (EXT4_ATOMICWRITES_FL which uses FS_ATOMICWRITES_FL flag).
>> Also add support for setting of this flag via ioctl.
>> 
>> Co-developed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
>> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
>> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>> ---
>>  fs/ext4/ext4.h  |  6 ++++++
>>  fs/ext4/ioctl.c | 11 +++++++++++
>>  2 files changed, 17 insertions(+)
>> 
>> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
>> index 1d2bce26e616..aa7fff2d6f96 100644
>> --- a/fs/ext4/ext4.h
>> +++ b/fs/ext4/ext4.h
>> @@ -495,8 +495,12 @@ struct flex_groups {
>>  #define EXT4_EA_INODE_FL	        0x00200000 /* Inode used for large EA */
>>  /* 0x00400000 was formerly EXT4_EOFBLOCKS_FL */
>>  
>> +#define EXT4_ATOMICWRITES_FL		FS_ATOMICWRITES_FL /* Inode supports atomic writes */
>>  #define EXT4_DAX_FL			0x02000000 /* Inode is DAX */
>
> Tying the on disk format to the kernel user API is a poor choice.
> While the flag bits might have the same value, anything parsing the
> on-disk format should not be required to include kernel syscall API
> header files just to get all the on-disk format definitions it
> needs.

sure. Make sense.
I will hardcode that value.

-ritesh

>
> -Dave.
> -- 
> Dave Chinner
> david@fromorbit.com