[fuse] Relevance of st_ino values

[fuse] Relevance of st_ino values

[Nikolaus Rath]

Hello,

For several requests, FUSE userspace returns a struct stat to the
kernel. struct stat includes an st_ino field, but FUSE generally has a
separate field for the inode (e.g. fuse_entry_param.ino vs
fuse_entry_param.attr.st_ino).

Does the kernel use the st_ino value at all, or is just passed through
to userspace?

If it is just passed through, is there a need for st_ino to match the
"real" inode?

Background:

Given that userspace has no use for inode values other than comparing
them for equality, I would have expected that st_ino can basically be
anything as long as there's some 1:1 mapping to kernel inodes. However,
I have seen changes in userspace behavior when setting st_ino to the
kernel inode (previously it was set to some other value by accident).


Thanks!
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: [fuse] Relevance of st_ino values

[Jean-Pierre André]

Nikolaus Rath wrote:
> Hello,
>
> For several requests, FUSE userspace returns a struct stat to the
> kernel. struct stat includes an st_ino field, but FUSE generally has a
> separate field for the inode (e.g. fuse_entry_param.ino vs
> fuse_entry_param.attr.st_ino).
>
> Does the kernel use the st_ino value at all, or is just passed through
> to userspace?

Fuse defines its own inode number in order to track the path used
to access a file. So, when a file is recorded in several directories,
it is referenced by fuse with several inode numbers.

>
> If it is just passed through, is there a need for st_ino to match the
> "real" inode?

There is no need. Files with several names have a single st_ino
value, and a fuse inode value per path met.

Unfortunately the inode numbers are used by the kernel to index
the caches, and the caches for files with several inode numbers
are not kept in sync (long standing issue...).

>
> Background:
>
> Given that userspace has no use for inode values other than comparing
> them for equality, I would have expected that st_ino can basically be
> anything as long as there's some 1:1 mapping to kernel inodes. However,
> I have seen changes in userspace behavior when setting st_ino to the
> kernel inode (previously it was set to some other value by accident).
>
>
> Thanks!
> -Nikolaus
>

Re: [fuse-devel] [fuse] Relevance of st_ino values

[Miklos Szeredi]

On Mon, Feb 11, 2019 at 12:18 PM Jean-Pierre André
<jean-pierre.andre@wanadoo.fr> wrote:
>
> Nikolaus Rath wrote:
> > Hello,
> >
> > For several requests, FUSE userspace returns a struct stat to the
> > kernel. struct stat includes an st_ino field, but FUSE generally has a
> > separate field for the inode (e.g. fuse_entry_param.ino vs
> > fuse_entry_param.attr.st_ino).
> >
> > Does the kernel use the st_ino value at all, or is just passed through
> > to userspace?

st_ino value is not used in any way by the kernel, just passed through
to userspace.

>
> Fuse defines its own inode number in order to track the path used
> to access a file. So, when a file is recorded in several directories,
> it is referenced by fuse with several inode numbers.

The high level lib does this, yes.

When using the lowlevel lib, it's up to the filesystem implementation:
passthrough_ll uses the struct lo_inode pointer (which is specific to
a certain real file) as nodeid, so no multi-caching (and related
problems with consistency) in case of hard links.

Thanks,
Miklos

Re: [fuse-devel] [fuse] Relevance of st_ino values

[Nikolaus Rath]

On Feb 11 2019, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Mon, Feb 11, 2019 at 12:18 PM Jean-Pierre André
> <jean-pierre.andre@wanadoo.fr> wrote:
>>
>> Nikolaus Rath wrote:
>> > Hello,
>> >
>> > For several requests, FUSE userspace returns a struct stat to the
>> > kernel. struct stat includes an st_ino field, but FUSE generally has a
>> > separate field for the inode (e.g. fuse_entry_param.ino vs
>> > fuse_entry_param.attr.st_ino).
>> >
>> > Does the kernel use the st_ino value at all, or is just passed through
>> > to userspace?
>
> st_ino value is not used in any way by the kernel, just passed through
> to userspace.

Thanks! And there is nothing that userspace can do with those numbers
other than comparing them to determine if two files are hardlinks of
each other, right? They cannot be passed back to the kernel in a
syscall?


Best,
-Nikolaus
-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: [fuse-devel] [fuse] Relevance of st_ino values

[Miklos Szeredi]

On Mon, Feb 11, 2019 at 9:44 PM Nikolaus Rath <Nikolaus@rath.org> wrote:
>
> On Feb 11 2019, Miklos Szeredi <miklos@szeredi.hu> wrote:
> > On Mon, Feb 11, 2019 at 12:18 PM Jean-Pierre André
> > <jean-pierre.andre@wanadoo.fr> wrote:
> >>
> >> Nikolaus Rath wrote:
> >> > Hello,
> >> >
> >> > For several requests, FUSE userspace returns a struct stat to the
> >> > kernel. struct stat includes an st_ino field, but FUSE generally has a
> >> > separate field for the inode (e.g. fuse_entry_param.ino vs
> >> > fuse_entry_param.attr.st_ino).
> >> >
> >> > Does the kernel use the st_ino value at all, or is just passed through
> >> > to userspace?
> >
> > st_ino value is not used in any way by the kernel, just passed through
> > to userspace.
>
> Thanks! And there is nothing that userspace can do with those numbers
> other than comparing them to determine if two files are hardlinks of
> each other, right? They cannot be passed back to the kernel in a
> syscall?

True and true.   If you want something to pass back to the kernel, see
the name_to_handle_at(2) and open_by_handle_at(2) syscalls.

POSIX states that

  "The st_ino and st_dev fields taken together uniquely identify the
file within the system."

FUSE takes care of providing a unique st_dev, so the filesystem only
has to care about providing a unique st_ino.  Note: it's perfectly
fine to reuse st_ino value of an already deleted file, so {st_dev,
st_ino} only has to guarantee uniqueness at every single point in
time, but not across different points in time.

Thanks,
Miklos