[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZcG/96H2zWmtSnyC@li-bb2b2a4c-3307-11b2-a85c-8fa5c3a69313.ibm.com>
Date: Tue, 6 Feb 2024 10:43:27 +0530
From: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
To: "Theodore Ts'o" <tytso@....edu>,
g@...bb2b2a4c-3307-11b2-a85c-8fa5c3a69313.ibm.com
Cc: linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org, jack@...e.cz,
ritesh.list@...il.com, john.g.garry@...cle.com, djwong@...nel.org
Subject: Re: Running out of inode flags in ext4
On Mon, Feb 05, 2024 at 11:32:49AM -0500, Theodore Ts'o wrote:
> On Mon, Feb 05, 2024 at 03:38:54PM +0530, Ojaswin Mujoo wrote:
> > 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).
>
> We still have some unused flags. For example,
> 0x01000000. 0x04000000. and 0x08000000 are still unused. We are
> starting to get close to full, so we need to be a bit careful since it
> is very much a limited resource. But we're not yet at the point where
> we need to worry about trying to reuse flags like EXT4_EOFBLOCKS_FL.
Hi Ted,
Thats true, i don't even know how I missed that :) Sorry for the noise.
Regards,
ojaswin
>
> Cheers,
>
> - Ted
Powered by blists - more mailing lists