[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fuse-devel
Subject:    Re: [fuse-devel] Question regarding readdir returning entry inodeIDs
From:       "Michael j Theall" <mtheall () us ! ibm ! com>
Date:       2016-01-06 17:29:51
Message-ID: OFBA37601F.F7B7072B-ON86257F32.005FEDB1-86257F32.00601E24 () notes ! na ! collabserv ! com
[Download RAW message or body]


Nikolaus Rath <Nikolaus@rath.org> wrote on 01/06/2016 11:14:26 AM:

> From: Nikolaus Rath <Nikolaus@rath.org>
> To: fuse-devel@lists.sourceforge.net
> Date: 01/06/2016 11:15 AM
> Subject: Re: [fuse-devel] Question regarding readdir returning entryinode
IDs
>
> On Jan 06 2016, Brian Byrne <brian.byrne-
> SXLT7ot9RyklJYEl4FgAsw@public.gmane.org> wrote:
> > Quick background, the underlying file system is distributed FS uses
> > inode IDs that don't map directly to 64-bit integers; this is fine, as
> > a virtual FUSE inode ID can be maintained for every FS inode ID.
> > Generally, these virtual inode IDs are allocated upon the first
> > encounter of the inode (via 'create' or 'lookup'), and the mapping
> > subsequently discarded when 'forget' is received.
> >
> > However, 'readdir' may be problematic because it requires every
> > entry's virtual inode ID to be returned, but there's no subsequent
> > 'forget' call for these entries. Therefore, it cannot be determined
> > when the virtual inode ID mapping can be discarded, since the kernel
> > could cache the virtual inode ID indefinitely.
>
> I believe that when using readdir, the inode is just discarded and not
> used. This differs when using readdirplus (but in that case you will get
> a forget request).
>

The inode is discarded, but it is passed to the end-user as-is. I know some
applications rely on that value (like a backup application to avoid backing
up the same hard link more than once) so you might want to be careful about
that.

Regards,
Michael Theall

>
> > However, 'readdir' should always be enclosed by an
> > 'opendir'/'releasedir', which would be useful if it can be guaranteed
> > that no returned 'readdir' inode IDs will be referenced once
> > 'releasedir' has been called.
>
> You have an even stronger guarantee: you will never receive any requests
> for an inode with a zero lookup count.
>
>
> Best,
> -Nikolaus
>
> (No Cc on replies please, I'm reading the list)
> --
> GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
> Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
>
>              =BBTime flies like an arrow, fruit flies like a Banana.=AB
>
>
---------------------------------------------------------------------------=
---

> _______________________________________________
> fuse-devel mailing list
> fuse-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fuse-devel
---------------------------------------------------------------------------=
---
_______________________________________________
fuse-devel mailing list
fuse-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel
[prev in list] [next in list] [prev in thread] [next in thread]