Who bumps nlookup on open?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Who bumps nlookup on open?

Consus
Hi guys,

I use lowlevel API and I'm curios at which point nlookup goes from zero
to one. Could someone point me to the right place in the code, I can't
find it (in master branch)?

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Who bumps nlookup on open?

Consus
On 16:26 Thu 27 Oct, Consus wrote:
> Hi guys,
>
> I use lowlevel API and I'm curios at which point nlookup goes from zero
> to one. Could someone point me to the right place in the code, I can't
> find it (in master branch)?

Stupid me, it's in the kernel. I guess, my question is more generic: can
I bump my inode's internal reference counter (as I use my own inode
structure outside of fuse callbacks) after successful call to
fuse_reply_open()? Can I rely on the kernel to send me forget request if
anything goes wrong (I'm aware that FUSE does not guarantee to send me
forget's on unmount event, I'm prepared for that).

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Who bumps nlookup on open?

Nikolaus Rath
On Oct 27 2016, Consus <[hidden email]> wrote:
> On 16:26 Thu 27 Oct, Consus wrote:
>> Hi guys,
>>
>> I use lowlevel API and I'm curios at which point nlookup goes from zero
>> to one. Could someone point me to the right place in the code, I can't
>> find it (in master branch)?
>
> Stupid me, it's in the kernel.

Well, the kernel probably keeps count as well, but that doesn't help
you. You need to maintain the count in your file system code. See
https://bitbucket.org/nikratio/python-llfuse/src/tip/developer-notes/lookup_counts.rst
for some notes on this (most of it applies to C code as well).

> I guess, my question is more generic: can
> I bump my inode's internal reference counter (as I use my own inode
> structure outside of fuse callbacks) after successful call to
> fuse_reply_open()?

Well, of course you can, but what would it achieve? You'll never receive
a forget request for it.


> Can I rely on the kernel to send me forget request if
> anything goes wrong (I'm aware that FUSE does not guarantee to send me
> forget's on unmount event, I'm prepared for that).

What do you mean with "anything goes wrong"? You will get a forget
request for each succesfull call to fuse_reply_entry, fuse_reply_create,
and (in FUSE3) responses to readdirplus.


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

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

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Who bumps nlookup on open?

Consus
On 09:00 Thu 27 Oct, Nikolaus Rath wrote:

> On Oct 27 2016, Consus <[hidden email]> wrote:
> > On 16:26 Thu 27 Oct, Consus wrote:
> >> Hi guys,
> >>
> >> I use lowlevel API and I'm curios at which point nlookup goes from zero
> >> to one. Could someone point me to the right place in the code, I can't
> >> find it (in master branch)?
> >
> > Stupid me, it's in the kernel.
>
> Well, the kernel probably keeps count as well, but that doesn't help
> you. You need to maintain the count in your file system code. See
> https://bitbucket.org/nikratio/python-llfuse/src/tip/developer-notes/lookup_counts.rst
> for some notes on this (most of it applies to C code as well).

Well yeah, I have a separate reference counter (because an inode may be
referenced outside of FUSE). I want to use nlookup as a boolean flag:

        if (nlookup == 1)
                ref_cnt++;

        if (nlookup == 0)
                ref_cnt--;

> > I guess, my question is more generic: can
> > I bump my inode's internal reference counter (as I use my own inode
> > structure outside of fuse callbacks) after successful call to
> > fuse_reply_open()?
>
> Well, of course you can, but what would it achieve? You'll never receive
> a forget request for it.

Yes, indeed. I should stick to fuse_reply_entry().

> > Can I rely on the kernel to send me forget request if
> > anything goes wrong (I'm aware that FUSE does not guarantee to send me
> > forget's on unmount event, I'm prepared for that).
>
> What do you mean with "anything goes wrong"? You will get a forget
> request for each succesfull call to fuse_reply_entry, fuse_reply_create,
> and (in FUSE3) responses to readdirplus.

I mean that sending a response to the kernel can fail and I check for it
(fuse_reply_entry returns an error value). After that the kernel by
itself processes the response and also can fail to do it. So will I
receive a forget in that case (the kernel failed to process the
response)?

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Who bumps nlookup on open?

Michael Theall-2
In reply to this post by Consus
> I guess, my question is more generic: can
> I bump my inode's internal reference counter (as I use my own inode
> structure outside of fuse callbacks) after successful call to
> fuse_reply_open()?

Yes. Obviously, you won't get a forget() request, but you can
decrement your reference count on a release() request.

Regards,
Michael Theall

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Who bumps nlookup on open?

Nikolaus Rath
In reply to this post by Consus
On Oct 28 2016, Consus <[hidden email]> wrote:

> On 09:00 Thu 27 Oct, Nikolaus Rath wrote:
>> On Oct 27 2016, Consus <[hidden email]> wrote:
>> > On 16:26 Thu 27 Oct, Consus wrote:
>> >> Hi guys,
>> >>
>> >> I use lowlevel API and I'm curios at which point nlookup goes from zero
>> >> to one. Could someone point me to the right place in the code, I can't
>> >> find it (in master branch)?
>> >
>> > Stupid me, it's in the kernel.
>>
>> Well, the kernel probably keeps count as well, but that doesn't help
>> you. You need to maintain the count in your file system code. See
>> https://bitbucket.org/nikratio/python-llfuse/src/tip/developer-notes/lookup_counts.rst
>> for some notes on this (most of it applies to C code as well).
>
> Well yeah, I have a separate reference counter (because an inode may be
> referenced outside of FUSE). I want to use nlookup as a boolean flag:
>
> if (nlookup == 1)
> ref_cnt++;
>
> if (nlookup == 0)
> ref_cnt--;

That does not make sense to me. Are you talking about the nlookup that's
passed to the forget() handler? In that case it will never be zero, and
may be larger than one.

>>> Can I rely on the kernel to send me forget request if
>>> anything goes wrong (I'm aware that FUSE does not guarantee to send me
>>> forget's on unmount event, I'm prepared for that).
>>
>> What do you mean with "anything goes wrong"? You will get a forget
>> request for each succesfull call to fuse_reply_entry, fuse_reply_create,
>> and (in FUSE3) responses to readdirplus.
>
> I mean that sending a response to the kernel can fail and I check for it
> (fuse_reply_entry returns an error value). After that the kernel by
> itself processes the response and also can fail to do it. So will I
> receive a forget in that case (the kernel failed to process the
> response)?

If you are sending a well-formed response, the kernel should not fail to
process it. So we are talking about the behavior if there is a bug in
either libfuse or the kernel. In that case, the behavior depends on what
exactly the postulated bug is. In other words, your question cannot be
answered.



Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

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

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Who bumps nlookup on open?

Consus
On 12:09 Fri 28 Oct, Nikolaus Rath wrote:

> On Oct 28 2016, Consus <[hidden email]> wrote:
> > On 09:00 Thu 27 Oct, Nikolaus Rath wrote:
> >> On Oct 27 2016, Consus <[hidden email]> wrote:
> >> > On 16:26 Thu 27 Oct, Consus wrote:
> >> >> Hi guys,
> >> >>
> >> >> I use lowlevel API and I'm curios at which point nlookup goes from zero
> >> >> to one. Could someone point me to the right place in the code, I can't
> >> >> find it (in master branch)?
> >> >
> >> > Stupid me, it's in the kernel.
> >>
> >> Well, the kernel probably keeps count as well, but that doesn't help
> >> you. You need to maintain the count in your file system code. See
> >> https://bitbucket.org/nikratio/python-llfuse/src/tip/developer-notes/lookup_counts.rst
> >> for some notes on this (most of it applies to C code as well).
> >
> > Well yeah, I have a separate reference counter (because an inode may be
> > referenced outside of FUSE). I want to use nlookup as a boolean flag:
> >
> > if (nlookup == 1)
> > ref_cnt++;
> >
> > if (nlookup == 0)
> > ref_cnt--;
>
> That does not make sense to me. Are you talking about the nlookup that's
> passed to the forget() handler? In that case it will never be zero, and
> may be larger than one.

Err... A quote from fuse_lowlevel.h:

         * The inode's lookup count increases by one for every call to
         * fuse_reply_entry and fuse_reply_create. The nlookup parameter
         * indicates by how much the lookup count should be decreased.
         *
         * Inodes with a non-zero lookup count may receive request from
         * the kernel even after calls to unlink, rmdir or (when
         * overwriting an existing file) rename. Filesystems must handle
         * such requests properly and it is recommended to defer removal
         * of the inode until the lookup count reaches zero. Calls to
         * unlink, remdir or rename will be followed closely by forget
         * unless the file or directory is open, in which case the
         * kernel issues forget only after the release or releasedir
         * calls.
         ...
         * On unmount the lookup count for all inodes implicitly drops
         * to zero. It is not guaranteed that the file system will
         * receive corresponding forget messages for the affected
         * inodes.
 

> >>> Can I rely on the kernel to send me forget request if
> >>> anything goes wrong (I'm aware that FUSE does not guarantee to send me
> >>> forget's on unmount event, I'm prepared for that).
> >>
> >> What do you mean with "anything goes wrong"? You will get a forget
> >> request for each succesfull call to fuse_reply_entry, fuse_reply_create,
> >> and (in FUSE3) responses to readdirplus.
> >
> > I mean that sending a response to the kernel can fail and I check for it
> > (fuse_reply_entry returns an error value). After that the kernel by
> > itself processes the response and also can fail to do it. So will I
> > receive a forget in that case (the kernel failed to process the
> > response)?
>
> If you are sending a well-formed response, the kernel should not fail to
> process it. So we are talking about the behavior if there is a bug in
> either libfuse or the kernel. In that case, the behavior depends on what
> exactly the postulated bug is. In other words, your question cannot be
> answered.

Have you actually read the kernel code? At least it can fail to allocate
memory for some of it's internal buffers (and yeah, in that case it will
generate a "forget" message though I'm not guaranteed to receive it for
the very same reason).

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Who bumps nlookup on open?

Consus
On 09:13 Sat 29 Oct, Consus wrote:

> On 12:09 Fri 28 Oct, Nikolaus Rath wrote:
> > On Oct 28 2016, Consus <[hidden email]> wrote:
> > > On 09:00 Thu 27 Oct, Nikolaus Rath wrote:
> > >> On Oct 27 2016, Consus <[hidden email]> wrote:
> > >> > On 16:26 Thu 27 Oct, Consus wrote:
> > >> >> Hi guys,
> > >> >>
> > >> >> I use lowlevel API and I'm curios at which point nlookup goes from zero
> > >> >> to one. Could someone point me to the right place in the code, I can't
> > >> >> find it (in master branch)?
> > >> >
> > >> > Stupid me, it's in the kernel.
> > >>
> > >> Well, the kernel probably keeps count as well, but that doesn't help
> > >> you. You need to maintain the count in your file system code. See
> > >> https://bitbucket.org/nikratio/python-llfuse/src/tip/developer-notes/lookup_counts.rst
> > >> for some notes on this (most of it applies to C code as well).
> > >
> > > Well yeah, I have a separate reference counter (because an inode may be
> > > referenced outside of FUSE). I want to use nlookup as a boolean flag:
> > >
> > > if (nlookup == 1)
> > > ref_cnt++;
> > >
> > > if (nlookup == 0)
> > > ref_cnt--;
> >
> > That does not make sense to me. Are you talking about the nlookup that's
> > passed to the forget() handler? In that case it will never be zero, and
> > may be larger than one.
>
> Err... A quote from fuse_lowlevel.h:
>
>          * The inode's lookup count increases by one for every call to
>          * fuse_reply_entry and fuse_reply_create. The nlookup parameter
>          * indicates by how much the lookup count should be decreased.
>          *
>          * Inodes with a non-zero lookup count may receive request from
>          * the kernel even after calls to unlink, rmdir or (when
>          * overwriting an existing file) rename. Filesystems must handle
>          * such requests properly and it is recommended to defer removal
>          * of the inode until the lookup count reaches zero. Calls to
>          * unlink, remdir or rename will be followed closely by forget
>          * unless the file or directory is open, in which case the
>          * kernel issues forget only after the release or releasedir
>          * calls.
> ...
>          * On unmount the lookup count for all inodes implicitly drops
>          * to zero. It is not guaranteed that the file system will
>          * receive corresponding forget messages for the affected
>          * inodes.

Just to be on the same page:

        struct my_inode {
                uint64_t        lookup_cnt;
                atomic_uint64_t ref_cnt;
        }

        lookup:
                inode = get_inode(id);
                inode->lookup_cnt++;
                if (inode->lookup_cnt == 1)
                        inode->ref_cnt++; (atomic)
                put_inode(inode);

        forget:
                inode->lookup_cnt -= forget_cnt;
                if (inode->lookup_cnt == 0)
                        inode->ref_cnt--; (atomic)

        (unmount)
                for all inodes:
                        inode->lookup_cnt = 0;
                        inode->ref_cnt--; (atomic)

Looks like your python doc you mentioned above. But because my inode
should be referenced outside of the FUSE code and I cannot be sure that
I will receive all forget messages (see the quote above) I have to
implement two counters -- FUSE reference counter (that should be dropped
to zero on unmount as per comments in fuse_lowlevel.h) and the actual
reference counter.

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Who bumps nlookup on open?

Roger Willcocks-2

On 29 Oct 2016, at 07:29, Consus <[hidden email]> wrote:

>
> Just to be on the same page:
>
> struct my_inode {
> uint64_t        lookup_cnt;
> atomic_uint64_t ref_cnt;
> }
>
> lookup:
> inode = get_inode(id);
> inode->lookup_cnt++;
> if (inode->lookup_cnt == 1)
> inode->ref_cnt++; (atomic)
> put_inode(inode);
>
> forget:
> inode->lookup_cnt -= forget_cnt;
> if (inode->lookup_cnt == 0)
> inode->ref_cnt--; (atomic)
>
> (unmount)
> for all inodes:
> inode->lookup_cnt = 0;
> inode->ref_cnt--; (atomic)
>

unmount can just call forget(inode->lookup_cnt)

You don’t need ref_cnt since it’s logically identical to (lookup_cnt != 0)


Roger



------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Who bumps nlookup on open?

Consus
On 10:59 Sat 29 Oct, Roger Willcocks wrote:

>
> On 29 Oct 2016, at 07:29, Consus <[hidden email]> wrote:
>
> >
> > Just to be on the same page:
> >
> > struct my_inode {
> > uint64_t        lookup_cnt;
> > atomic_uint64_t ref_cnt;
> > }
> >
> > lookup:
> > inode = get_inode(id);
> > inode->lookup_cnt++;
> > if (inode->lookup_cnt == 1)
> > inode->ref_cnt++; (atomic)
> > put_inode(inode);
> >
> > forget:
> > inode->lookup_cnt -= forget_cnt;
> > if (inode->lookup_cnt == 0)
> > inode->ref_cnt--; (atomic)
> >
> > (unmount)
> > for all inodes:
> > inode->lookup_cnt = 0;
> > inode->ref_cnt--; (atomic)
> >
>
> unmount can just call forget(inode->lookup_cnt)
>
> You don’t need ref_cnt since it’s logically identical to (lookup_cnt != 0)

According to the documentation it's not guaranteed that fuse will call a
"forget" handler for each affected inode.

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Who bumps nlookup on open?

Nikolaus Rath
In reply to this post by Consus
On Oct 29 2016, Consus <[hidden email]> wrote:

> On 12:09 Fri 28 Oct, Nikolaus Rath wrote:
>> On Oct 28 2016, Consus <[hidden email]> wrote:
>> > On 09:00 Thu 27 Oct, Nikolaus Rath wrote:
>> >> On Oct 27 2016, Consus <[hidden email]> wrote:
>> >> > On 16:26 Thu 27 Oct, Consus wrote:
>> >> >> Hi guys,
>> >> >>
>> >> >> I use lowlevel API and I'm curios at which point nlookup goes from zero
>> >> >> to one. Could someone point me to the right place in the code, I can't
>> >> >> find it (in master branch)?
>> >> >
>> >> > Stupid me, it's in the kernel.
>> >>
>> >> Well, the kernel probably keeps count as well, but that doesn't help
>> >> you. You need to maintain the count in your file system code. See
>> >> https://bitbucket.org/nikratio/python-llfuse/src/tip/developer-notes/lookup_counts.rst
>> >> for some notes on this (most of it applies to C code as well).
>> >
>> > Well yeah, I have a separate reference counter (because an inode may be
>> > referenced outside of FUSE). I want to use nlookup as a boolean flag:
>> >
>> > if (nlookup == 1)
>> > ref_cnt++;
>> >
>> > if (nlookup == 0)
>> > ref_cnt--;
>>
>> That does not make sense to me. Are you talking about the nlookup that's
>> passed to the forget() handler? In that case it will never be zero, and
>> may be larger than one.
>
> Err... A quote from fuse_lowlevel.h:
>
>          * The inode's lookup count increases by one for every call to
>          * fuse_reply_entry and fuse_reply_create. The nlookup parameter
>          * indicates by how much the lookup count should be decreased.
>          *
>          * Inodes with a non-zero lookup count may receive request from
>          * the kernel even after calls to unlink, rmdir or (when
>          * overwriting an existing file) rename. Filesystems must handle
>          * such requests properly and it is recommended to defer removal
>          * of the inode until the lookup count reaches zero. Calls to
>          * unlink, remdir or rename will be followed closely by forget
>          * unless the file or directory is open, in which case the
>          * kernel issues forget only after the release or releasedir
>          * calls.
> ...
>          * On unmount the lookup count for all inodes implicitly drops
>          * to zero. It is not guaranteed that the file system will
>          * receive corresponding forget messages for the affected
>          * inodes.

I am not sure what you are trying to say. In my opinion, this is
consistent with what I wrote above.

>> >>> Can I rely on the kernel to send me forget request if
>> >>> anything goes wrong (I'm aware that FUSE does not guarantee to send me
>> >>> forget's on unmount event, I'm prepared for that).
>> >>
>> >> What do you mean with "anything goes wrong"? You will get a forget
>> >> request for each succesfull call to fuse_reply_entry, fuse_reply_create,
>> >> and (in FUSE3) responses to readdirplus.
>> >
>> > I mean that sending a response to the kernel can fail and I check for it
>> > (fuse_reply_entry returns an error value). After that the kernel by
>> > itself processes the response and also can fail to do it. So will I
>> > receive a forget in that case (the kernel failed to process the
>> > response)?
>>
>> If you are sending a well-formed response, the kernel should not fail to
>> process it. So we are talking about the behavior if there is a bug in
>> either libfuse or the kernel. In that case, the behavior depends on what
>> exactly the postulated bug is. In other words, your question cannot be
>> answered.
>
> Have you actually read the kernel code? At least it can fail to allocate
> memory for some of it's internal buffers (and yeah, in that case it will
> generate a "forget" message though I'm not guaranteed to receive it for
> the very same reason).

Again, we seem to be in agreement.


Best,
Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

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

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Who bumps nlookup on open?

Consus
On 10:23 Mon 31 Oct, Nikolaus Rath wrote:
> I am not sure what you are trying to say. In my opinion, this is
> consistent with what I wrote above.

I have two separate reference counters because on unmount event the
lookup counter drops to zero _implicitly_ which means I don't know how
many times to decrement the counter. And my inode can be referenced not
only by the kernel (via lookup) but also by my internal stuff.

But I guess my questions were asnwered.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Loading...