Linux-Fsdevel Archive on lore.kernel.org
 help / Atom feed
* [fuse] Relevance of st_ino values
@ 2019-02-10 21:15 Nikolaus Rath
  2019-02-11 11:18 ` Jean-Pierre André
  0 siblings, 1 reply; 5+ messages in thread
From: Nikolaus Rath @ 2019-02-10 21:15 UTC (permalink / raw)
  To: fuse-devel, Miklos Szeredi, linux-fsdevel

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.«

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [fuse] Relevance of st_ino values
  2019-02-10 21:15 [fuse] Relevance of st_ino values Nikolaus Rath
@ 2019-02-11 11:18 ` Jean-Pierre André
  2019-02-11 15:59   ` [fuse-devel] " Miklos Szeredi
  0 siblings, 1 reply; 5+ messages in thread
From: Jean-Pierre André @ 2019-02-11 11:18 UTC (permalink / raw)
  To: linux-fsdevel; +Cc: fuse-devel

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
>



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [fuse-devel] [fuse] Relevance of st_ino values
  2019-02-11 11:18 ` Jean-Pierre André
@ 2019-02-11 15:59   ` " Miklos Szeredi
  2019-02-11 20:44     ` Nikolaus Rath
  0 siblings, 1 reply; 5+ messages in thread
From: Miklos Szeredi @ 2019-02-11 15:59 UTC (permalink / raw)
  To: Jean-Pierre André; +Cc: fuse-devel, linux-fsdevel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [fuse-devel] [fuse] Relevance of st_ino values
  2019-02-11 15:59   ` [fuse-devel] " Miklos Szeredi
@ 2019-02-11 20:44     ` Nikolaus Rath
  2019-02-12  9:02       ` Miklos Szeredi
  0 siblings, 1 reply; 5+ messages in thread
From: Nikolaus Rath @ 2019-02-11 20:44 UTC (permalink / raw)
  To: Miklos Szeredi; +Cc: Jean-Pierre André, fuse-devel, linux-fsdevel

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.«

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [fuse-devel] [fuse] Relevance of st_ino values
  2019-02-11 20:44     ` Nikolaus Rath
@ 2019-02-12  9:02       ` Miklos Szeredi
  0 siblings, 0 replies; 5+ messages in thread
From: Miklos Szeredi @ 2019-02-12  9:02 UTC (permalink / raw)
  To: fuse-devel; +Cc: Jean-Pierre André, linux-fsdevel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-10 21:15 [fuse] Relevance of st_ino values Nikolaus Rath
2019-02-11 11:18 ` Jean-Pierre André
2019-02-11 15:59   ` [fuse-devel] " Miklos Szeredi
2019-02-11 20:44     ` Nikolaus Rath
2019-02-12  9:02       ` Miklos Szeredi

Linux-Fsdevel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \
		linux-fsdevel@vger.kernel.org linux-fsdevel@archiver.kernel.org
	public-inbox-index linux-fsdevel


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox