[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260119070527.GB1480@lst.de>
Date: Mon, 19 Jan 2026 08:05:27 +0100
From: Christoph Hellwig <hch@....de>
To: Namjae Jeon <linkinjeon@...nel.org>
Cc: Christoph Hellwig <hch@....de>, viro@...iv.linux.org.uk,
brauner@...nel.org, tytso@....edu, willy@...radead.org,
jack@...e.cz, djwong@...nel.org, josef@...icpanda.com,
sandeen@...deen.net, rgoldwyn@...e.com, xiang@...nel.org,
dsterba@...e.com, pali@...nel.org, ebiggers@...nel.org,
neil@...wn.name, amir73il@...il.com, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, iamjoonsoo.kim@....com,
cheol.lee@....com, jay.sim@....com, gunho.lee@....com
Subject: Re: [PATCH v5 02/14] ntfs: update in-memory, on-disk structures
and headers
On Sun, Jan 18, 2026 at 01:54:06PM +0900, Namjae Jeon wrote:
> > It seem like big_ntfs_inode is literally only used in the conversion
> > helpers below. Are there are a lot of these "extent inode" so that
> > not having the vfs inode for them is an actual saving?
> Right, In NTFS, a base MFT record (represented by the base ntfs_inode)
> requires a struct inode to interact with the VFS. However, a single
> file can have multiple extent MFT records to store additional
> attributes. These extent inodes are managed internally by the base
> inode and do not need to be visible to the VFS.
What are typical numbers of the extra extent inodes? If they are rare,
you might be able to simplify the code a bit by just always allocating
the vfs_inode even if it's not really used.
Nothing important, though - just thinking along.
Powered by blists - more mailing lists