Re: [PATCH 0/3] show orphan file inode detail info

Re: [PATCH 0/3] show orphan file inode detail info

[Jan Kara]

Hi!

On Fri 03-04-26 16:25:04, Ye Bin wrote:
> From: Ye Bin <yebin10@huawei.com>
> 
> In actual production environments, the issue of inconsistency between
> df and du is frequently encountered. In many cases, the cause of the
> problem can be identified through the use of lsof. However, when
> overlayfs is combined with project quota configuration, the issue becomes
> more complex and troublesome to diagnose. First, to determine the project
> ID, one needs to obtain orphaned nodes using `fsck.ext4 -fn /dev/xx`, and
> then retrieve file information through `debugfs`. However, the file names
> cannot always be obtained, and it is often unclear which files they are.
> To identify which files these are, one would need to use crash for online
> debugging or use kprobe to gather information incrementally. However, some
> customers in production environments do not agree to upload any tools, and
> online debugging might impact the business. There are also scenarios where
> files are opened in kernel mode, which do not generate file descriptors(fds),
> making it impossible to identify which files were deleted but still have
> references through lsof. This patchset adds a procfs interface to query
> information about orphaned nodes, which can assist in the analysis and
> localization of such issues.

I agree listing orphan inodes for a superblock is useful and the usefulness
could actually go beyond ext4. I imagine the very same problem is there for
XFS or btrfs so perhaps we could think for a while whether we can provide
an interface that wouldn't be ext4 specific? Perhaps an ioctl
(GET_ORPHAN_FILES) that would return an fd and reading from that fd would
return entries for orphan inodes?

Also regarding information reported about orphan inodes - won't it be better
interface to just return a list of file handles? Userspace can then do
whatever it needs with them - open, statx, calling ioctl, etc - so we
thwart feature creep with people asking us to add more information to the
interface. This also offloads a lot of security questions about the
interface to appropriate syscalls. So overall it looks like a win to me.

								Honza

> 
> Ye Bin (3):
>   ext4: register 'orphan_list' procfs
>   ext4: show inode orphan list detail information
>   ext4: show orphan file inode detail info
> 
>  fs/ext4/ext4.h   |   1 +
>  fs/ext4/orphan.c | 227 +++++++++++++++++++++++++++++++++++++++++++++++
>  fs/ext4/sysfs.c  |   2 +
>  3 files changed, 230 insertions(+)
> 
> -- 
> 2.34.1
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH 0/3] show orphan file inode detail info

[Theodore Tso]

On Tue, Apr 07, 2026 at 12:29:23PM +0200, Jan Kara wrote:
> I agree listing orphan inodes for a superblock is useful and the usefulness
> could actually go beyond ext4. I imagine the very same problem is there for
> XFS or btrfs so perhaps we could think for a while whether we can provide
> an interface that wouldn't be ext4 specific? Perhaps an ioctl
> (GET_ORPHAN_FILES) that would return an fd and reading from that fd would
> return entries for orphan inodes?

I'm really not a fan of ioctl's returning a fd, but that does seem to
be a thing these days, for better or for worse, and I agree that
having a portable solution that works across multiple file systems
would be a good thing.

> Also regarding information reported about orphan inodes - won't it be better
> interface to just return a list of file handles? Userspace can then do
> whatever it needs with them - open, statx, calling ioctl, etc - so we
> thwart feature creep with people asking us to add more information to the
> interface. This also offloads a lot of security questions about the
> interface to appropriate syscalls. So overall it looks like a win to me.

The problem with using a file handle is that the only way to get the
pathname is to open the file handle, and then call readlink on
/proc/self/fd/NN.  And inodes on the orphan inode list have been
unlinked, so we don't want to allow people to be able to open them.  I
suppose we could allow this via O_PATH, but I'm not sure that this is
guaranteed to work across all filesystems' file handles?

	      	   	      		   - Ted

Re: [PATCH 0/3] show orphan file inode detail info

[Jan Kara]

On Tue 07-04-26 16:28:45, Theodore Tso wrote:
> On Tue, Apr 07, 2026 at 12:29:23PM +0200, Jan Kara wrote:
> > I agree listing orphan inodes for a superblock is useful and the usefulness
> > could actually go beyond ext4. I imagine the very same problem is there for
> > XFS or btrfs so perhaps we could think for a while whether we can provide
> > an interface that wouldn't be ext4 specific? Perhaps an ioctl
> > (GET_ORPHAN_FILES) that would return an fd and reading from that fd would
> > return entries for orphan inodes?
> 
> I'm really not a fan of ioctl's returning a fd, but that does seem to
> be a thing these days, for better or for worse, and I agree that
> having a portable solution that works across multiple file systems
> would be a good thing.

Yes, ioctl returning fd isn't great but frankly a file in /proc looks even
worse to me...

> > Also regarding information reported about orphan inodes - won't it be better
> > interface to just return a list of file handles? Userspace can then do
> > whatever it needs with them - open, statx, calling ioctl, etc - so we
> > thwart feature creep with people asking us to add more information to the
> > interface. This also offloads a lot of security questions about the
> > interface to appropriate syscalls. So overall it looks like a win to me.
> 
> The problem with using a file handle is that the only way to get the
> pathname is to open the file handle, and then call readlink on
> /proc/self/fd/NN.

Right, which is pretty standard I'd say.

> And inodes on the orphan inode list have been unlinked, so we don't want
> to allow people to be able to open them.

Why? You can reopen unlinked files using magic links in proc or file
handles just fine today (just tested this if I'm not missing anything in
the code). Only once the inode is really deleted you cannot open using the
handle anymore.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR