On 13/10/24 21:17, Jeff Layton wrote:
On Fri, 2024-10-11 at 17:30 +0200, Mickaël Salaün wrote:
On Fri, Oct 11, 2024 at 07:39:33AM -0700, Christoph Hellwig wrote:
On Fri, Oct 11, 2024 at 03:52:42PM +0200, Mickaël Salaün wrote:
Yes, but how do you call getattr() without a path?
You don't because inode numbers are irrelevant without the path.
They are for kernel messages and audit logs. Please take a look at the
use cases with the other patches.
It still is useless. E.g. btrfs has duplicate inode numbers due to
subvolumes.
At least it reflects what users see.
If you want a better pretty but not useful value just work on making
i_ino 64-bits wide, which is long overdue.
That would require too much work for me, and this would be a pain to
backport to all stable kernels.
Would it though? Adding this new inode operation seems sub-optimal.
Inode numbers are static information. Once an inode number is set on an
inode it basically never changes. This patchset will turn all of those
direct inode->i_ino fetches into a pointer chase for the new inode
operation, which will then almost always just result in a direct fetch.
A better solution here would be to make inode->i_ino a u64, and just
fix up all of the places that touch it to expect that. Then, just
ensure that all of the filesystems set it properly when instantiating
new inodes. Even on 32-bit arch, you likely wouldn't need a seqcount
loop or anything to fetch this since the chance of a torn read there is
basically zero.
If there are places where we need to convert i_ino down to 32-bits,
then we can just use some scheme like nfs_fattr_to_ino_t(), or just
cast i_ino to a u32.
Yes, it'd be a larger patchset, but that seems like it would be a
better solution.
As someone who lives in the analytical user space of Linux audit, I
take it that for large (say >200TB) file systems, the inode value
reported in audit PATH records is no longer forensically defensible and
it's use as a correlation item is of questionable value now?
