Received-SPF: pass (google.com: domain of linux-ext4+bounces-1097-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Mon, 5 Feb 2024 15:38:54 +0530
From: Ojaswin Mujoo <ojaswin@linux.ibm.com>
To: tytso@mit.edu
Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, jack@suse.cz,
        ritesh.list@gmail.com, john.g.garry@oracle.com, djwong@kernel.org
Subject: Running out of inode flags in ext4
Message-ID: <ZcCztkt8KtMrsvPp@li-bb2b2a4c-3307-11b2-a85c-8fa5c3a69313.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: bulk
MIME-Version: 1.0

Hi folks,

I'm trying to rework the ext4 atomic write patchset so we have similar
semantics as discussed here [1], which would look something like:

1. we call FS_IOC_FSSETXATTR to enable atomic write on inode

2. In the setxattr path, we need to mark the inode with
atomic_write_enabled. XFS does it via an on disk inode flag which is
straightforward enough 

However, on ext4 we are almost out of 32 bits of inode flags and I don't
think it's possible to add any flags2 field or something (iiuc, ondisk
indoe doesn't have scope for expansion).

Some ideas that I have:

- I see that 0x00400000 (formerly EXT4_EOFBLOCKS_FL) is free to use but
	as per my understanding, this is interpreted in some way by older fsck
	versions. However, marking atomic writes as RO_COMPAT might help aavoid
	confusion in fsck.

- If we can't use inode flags, should we maybe use xattr to store
	atomic_write details?
	
Should I go with either of above or is there a better way to mark
ext4 inodes which I might be missing. Also, now that we are out of inode
flags, what's the recommended way to handle such use cases in the
future?

Would appreciate some suggestions on this.

Thanks,
ojaswin

[1]
https://lore.kernel.org/all/20240124142645.9334-4-john.g.garry@oracle.com/