forget inodes

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

forget inodes

Stef Bon-2
Hello,

I'm looking at the forget mechanism.

As fas as I understand the kernel VFS sends a forget signal, to forget
a number of lookups.

What is the idea? To remove the inode when the number of lookups is
zero (or less..)?

What is triggering the forget call: what's making the vfs "decide" to
send a forget call?
A certain period unused?

Stef

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Nikolaus Rath
Stef Bon <[hidden email]> writes:
> Hello,
>
> I'm looking at the forget mechanism.
>
> As fas as I understand the kernel VFS sends a forget signal, to forget
> a number of lookups.

You're wrong, it's the other way around. Your FS tells the kernel to
forget about an inode.


Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

John Muir-2
Stef Bon <[hidden email]> writes:
> As fas as I understand the kernel VFS sends a forget signal, to forget
> a number of lookups.


The VFS-fuse will lookup() based on a parent inode and a file name, resulting in an inode with a lookup count incremented by 1. The lookup count is also set to 1 for creation of a file. It is possible that you will receive multiple lookup requests, in which case you are to increase your lookup counter.

While the inode is looked-up, the file-system should keep a record in it's cache because it can expect operations on that inode directly.

The kernel may forget inodes under three circumstances:
1. The inode is deleted and it is not open.
2. Pressure on the cache causes the kernel to free some cached information including that for the inode.
3. The file-system is unmounted (similar to 2, but freeing everything about the file-system) - although perhaps the default fuse implementation here is to suppress forget operations in this case (in the multi-threaded fuse loop function).

Essentially you should be keeping track of the inode while you have a lookup count that is larger than 0 so that you can do operations on it instantly without having to lookup the inode yourself.

Regards,

John.


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Nikolaus Rath
In reply to this post by Nikolaus Rath
Nikolaus Rath <[hidden email]> writes:

> Stef Bon <[hidden email]> writes:
>> Hello,
>>
>> I'm looking at the forget mechanism.
>>
>> As fas as I understand the kernel VFS sends a forget signal, to forget
>> a number of lookups.
>
> You're wrong, it's the other way around. Your FS tells the kernel to
> forget about an inode.

Actually I confused "forget" with "invalidate". Please disregard everything I
said and read John's mail instead.


   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Stef Bon-2
In reply to this post by John Muir-2
Thanks a lot.

Nikolas: I already understood that you were mixing things.

When unmounting, my fs is not storing anything, so then I do not do
anything with the forget calls.

To be sure, a forget call is only done because of "pressure on the
inode cache", an external factor, and not the
period an inode is not used for example. Something like an inode is "expired".

If that's true, that would be good thing.

My fs is cooperating with the automounter tou mount all kinds of
resources, local like USB and harddrives (partitions of), and remote
like SMB shares and FTP directories.

My operations work via an fd: openat, readlinkat, fstatat etc.

Now to perform the various calls on the mounts, I'm working on using
an fd pointing to the root of
the mounted fs. This fd will keep the share locked, and prevent the
automounter to umount it.

Now if all the inodes my fs creates to access the share are
"forgotten" (have been send a forget signal)
my  fs detects that and will remove the fd on the autofs managed
mount, giving it "back" to the automounter,
which on his turn will

Stef



2010/6/29 John Muir <[hidden email]>:

> Stef Bon <[hidden email]> writes:
>> As fas as I understand the kernel VFS sends a forget signal, to forget
>> a number of lookups.
>
>
> The VFS-fuse will lookup() based on a parent inode and a file name, resulting in an inode with a lookup count incremented by 1. The lookup count is also set to 1 for creation of a file. It is possible that you will receive multiple lookup requests, in which case you are to increase your lookup counter.
>
> While the inode is looked-up, the file-system should keep a record in it's cache because it can expect operations on that inode directly.
>
> The kernel may forget inodes under three circumstances:
> 1. The inode is deleted and it is not open.
> 2. Pressure on the cache causes the kernel to free some cached information including that for the inode.
> 3. The file-system is unmounted (similar to 2, but freeing everything about the file-system) - although perhaps the default fuse implementation here is to suppress forget operations in this case (in the multi-threaded fuse loop function).
>
> Essentially you should be keeping track of the inode while you have a lookup count that is larger than 0 so that you can do operations on it instantly without having to lookup the inode yourself.
>
> Regards,
>
> John.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> fuse-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/fuse-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Paul Schutte
Hi

I should actually rename this thread now to "Lookup reference count
broken when hardlinks are not implemented".

I believe I stumbled onto a bug while playing with the forget callback.
I noticed that the "lookup count" should increase when you hardlink a
file.

I then removed the (.link) callback from struct fuse_lowlevel_ops in my
fs (as I was chasing a bug). Hardlinks are now not implemented.
I then tried to hardlink files anyway and got the error as expected.

I noticed that the forget callback was then called with the same amount
of (nlookups - forget references) as if the hardlink operations had
succeeded. That left my with a negative reference count.

I think hardlink is sort of a special case because a filesystem could
function without hardlink, but not without the other functions that
should increase the "lookup count".

So, if you use forget to manage inode/file lifetimes, you better
implement hardlinks or you could have haywire reference counts and
possible double freeing of memory.

Regards
Paul


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Goswin von Brederlow-2
Paul Schutte <[hidden email]> writes:

> Hi
>
> I should actually rename this thread now to "Lookup reference count
> broken when hardlinks are not implemented".
>
> I believe I stumbled onto a bug while playing with the forget callback.
> I noticed that the "lookup count" should increase when you hardlink a
> file.
>
> I then removed the (.link) callback from struct fuse_lowlevel_ops in my
> fs (as I was chasing a bug). Hardlinks are now not implemented.
> I then tried to hardlink files anyway and got the error as expected.
>
> I noticed that the forget callback was then called with the same amount
> of (nlookups - forget references) as if the hardlink operations had
> succeeded. That left my with a negative reference count.
>
> I think hardlink is sort of a special case because a filesystem could
> function without hardlink, but not without the other functions that
> should increase the "lookup count".
>
> So, if you use forget to manage inode/file lifetimes, you better
> implement hardlinks or you could have haywire reference counts and
> possible double freeing of memory.
>
> Regards
> Paul

That sounds like a bug in fuse. Could you give  debug log?

MfG
        Goswin

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Stef Bon-2
Hardlinks are a whole different story.

What do you do when looking up a hardlink, is the number of lookups of
the target
of the link also incremented?

S.

2010/7/1 Goswin von Brederlow <[hidden email]>:

> Paul Schutte <[hidden email]> writes:
>
>> Hi
>>
>> I should actually rename this thread now to "Lookup reference count
>> broken when hardlinks are not implemented".
>>
>> I believe I stumbled onto a bug while playing with the forget callback.
>> I noticed that the "lookup count" should increase when you hardlink a
>> file.
>>
>> I then removed the (.link) callback from struct fuse_lowlevel_ops in my
>> fs (as I was chasing a bug). Hardlinks are now not implemented.
>> I then tried to hardlink files anyway and got the error as expected.
>>
>> I noticed that the forget callback was then called with the same amount
>> of (nlookups - forget references) as if the hardlink operations had
>> succeeded. That left my with a negative reference count.
>>
>> I think hardlink is sort of a special case because a filesystem could
>> function without hardlink, but not without the other functions that
>> should increase the "lookup count".
>>
>> So, if you use forget to manage inode/file lifetimes, you better
>> implement hardlinks or you could have haywire reference counts and
>> possible double freeing of memory.
>>
>> Regards
>> Paul
>
> That sounds like a bug in fuse. Could you give  debug log?
>
> MfG
>        Goswin
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> fuse-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/fuse-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Paul Schutte
Basically I build in a check in forget to warn me when the reference
goes negative. This should never happen.
I then caught a few negative references and figured out that when ever
you hard link a file, you should increase the reference as well
(regardless of the number of lookups that happend)
The reference count checks out 100% when you do that.

If you don't implement hard links and someone tries to hard link a file,
then the reference count for that inode goes negative (after you handle
the appropriate nlookups), which should not happen.

Hope this makes sense.
Paul


On Thu, 2010-07-01 at 13:22 +0200, Stef Bon wrote:

> Hardlinks are a whole different story.
>
> What do you do when looking up a hardlink, is the number of lookups of
> the target
> of the link also incremented?
>
> S.
>
> 2010/7/1 Goswin von Brederlow <[hidden email]>:
> > Paul Schutte <[hidden email]> writes:
> >
> >> Hi
> >>
> >> I should actually rename this thread now to "Lookup reference count
> >> broken when hardlinks are not implemented".
> >>
> >> I believe I stumbled onto a bug while playing with the forget callback.
> >> I noticed that the "lookup count" should increase when you hardlink a
> >> file.
> >>
> >> I then removed the (.link) callback from struct fuse_lowlevel_ops in my
> >> fs (as I was chasing a bug). Hardlinks are now not implemented.
> >> I then tried to hardlink files anyway and got the error as expected.
> >>
> >> I noticed that the forget callback was then called with the same amount
> >> of (nlookups - forget references) as if the hardlink operations had
> >> succeeded. That left my with a negative reference count.
> >>
> >> I think hardlink is sort of a special case because a filesystem could
> >> function without hardlink, but not without the other functions that
> >> should increase the "lookup count".
> >>
> >> So, if you use forget to manage inode/file lifetimes, you better
> >> implement hardlinks or you could have haywire reference counts and
> >> possible double freeing of memory.
> >>
> >> Regards
> >> Paul
> >
> > That sounds like a bug in fuse. Could you give  debug log?
> >
> > MfG
> >        Goswin
> >
> > ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > fuse-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/fuse-devel
> >
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> fuse-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/fuse-devel



------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Miklos Szeredi
On Thu, 01 Jul 2010, Paul Schutte wrote:
> Basically I build in a check in forget to warn me when the reference
> goes negative. This should never happen.
> I then caught a few negative references and figured out that when ever
> you hard link a file, you should increase the reference as well
> (regardless of the number of lookups that happend)
> The reference count checks out 100% when you do that.

Right.

More generally, every "creation" also counts as a lookup.

If the creation occured because of MKDIR, CREATE, MKNOD, SYMLINK, then
the count will be incremented from zero to one.

If the creation was because of a LINK then the count will be
incremented from N to N+1.

Thanks,
Miklos

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Paul Schutte

On Thu, 2010-07-01 at 14:16 +0200, Miklos Szeredi wrote:

> On Thu, 01 Jul 2010, Paul Schutte wrote:
> > Basically I build in a check in forget to warn me when the reference
> > goes negative. This should never happen.
> > I then caught a few negative references and figured out that when ever
> > you hard link a file, you should increase the reference as well
> > (regardless of the number of lookups that happend)
> > The reference count checks out 100% when you do that.
>
> Right.
>
> More generally, every "creation" also counts as a lookup.
>
> If the creation occured because of MKDIR, CREATE, MKNOD, SYMLINK, then
> the count will be incremented from zero to one.
>
> If the creation was because of a LINK then the count will be
> incremented from N to N+1.

This is how I understand it, but there is a problem if the filesystem
does not implement hardlinks.

On the fuse side it does the N+1 thing when doing a hardlink and expects
you to do N+1 on the users space side as well. Except you can't because
you did'nt implement hardlinks, so in user space you still sit with N.

Now in forget fuse want's you to forget (N+1) references. If you do that
you end up with N-(N+1)=-1 and there is the problem.

Regards
Paul


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Miklos Szeredi
On Thu, 01 Jul 2010, Paul Schutte wrote:
> This is how I understand it, but there is a problem if the filesystem
> does not implement hardlinks.
>
> On the fuse side it does the N+1 thing when doing a hardlink and expects
> you to do N+1 on the users space side as well. Except you can't because
> you did'nt implement hardlinks, so in user space you still sit with N.
>
> Now in forget fuse want's you to forget (N+1) references. If you do that
> you end up with N-(N+1)=-1 and there is the problem.

I don't understand.  If the filesystem doesn't implement hard links
then the LINK request will fail and the lookup count will not be
incremented.

Thanks,
Miklos

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Paul Schutte
That is why I say I think I stumbled onto a bug.
It looks like the lookup count (on the fuse side) does get incremented
even when the LINK request fails.

Regards
Paul

On Thu, 2010-07-01 at 15:34 +0200, Miklos Szeredi wrote:

> On Thu, 01 Jul 2010, Paul Schutte wrote:
> > This is how I understand it, but there is a problem if the filesystem
> > does not implement hardlinks.
> >
> > On the fuse side it does the N+1 thing when doing a hardlink and expects
> > you to do N+1 on the users space side as well. Except you can't because
> > you did'nt implement hardlinks, so in user space you still sit with N.
> >
> > Now in forget fuse want's you to forget (N+1) references. If you do that
> > you end up with N-(N+1)=-1 and there is the problem.
>
> I don't understand.  If the filesystem doesn't implement hard links
> then the LINK request will fail and the lookup count will not be
> incremented.
>
> Thanks,
> Miklos



------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Stef Bon-2
What interface you're using, lowlevel or high?

Stef

2010/7/1 Paul Schutte <[hidden email]>:

> That is why I say I think I stumbled onto a bug.
> It looks like the lookup count (on the fuse side) does get incremented
> even when the LINK request fails.
>
> Regards
> Paul
>
> On Thu, 2010-07-01 at 15:34 +0200, Miklos Szeredi wrote:
>> On Thu, 01 Jul 2010, Paul Schutte wrote:
>> > This is how I understand it, but there is a problem if the filesystem
>> > does not implement hardlinks.
>> >
>> > On the fuse side it does the N+1 thing when doing a hardlink and expects
>> > you to do N+1 on the users space side as well. Except you can't because
>> > you did'nt implement hardlinks, so in user space you still sit with N.
>> >
>> > Now in forget fuse want's you to forget (N+1) references. If you do that
>> > you end up with N-(N+1)=-1 and there is the problem.
>>
>> I don't understand.  If the filesystem doesn't implement hard links
>> then the LINK request will fail and the lookup count will not be
>> incremented.
>>
>> Thanks,
>> Miklos
>
>
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Paul Schutte
lowlevel 2.8.4.

On Thu, 2010-07-01 at 15:42 +0200, Stef Bon wrote:

> What interface you're using, lowlevel or high?
>
> Stef
>
> 2010/7/1 Paul Schutte <[hidden email]>:
> > That is why I say I think I stumbled onto a bug.
> > It looks like the lookup count (on the fuse side) does get incremented
> > even when the LINK request fails.
> >
> > Regards
> > Paul
> >
> > On Thu, 2010-07-01 at 15:34 +0200, Miklos Szeredi wrote:
> >> On Thu, 01 Jul 2010, Paul Schutte wrote:
> >> > This is how I understand it, but there is a problem if the filesystem
> >> > does not implement hardlinks.
> >> >
> >> > On the fuse side it does the N+1 thing when doing a hardlink and expects
> >> > you to do N+1 on the users space side as well. Except you can't because
> >> > you did'nt implement hardlinks, so in user space you still sit with N.
> >> >
> >> > Now in forget fuse want's you to forget (N+1) references. If you do that
> >> > you end up with N-(N+1)=-1 and there is the problem.
> >>
> >> I don't understand.  If the filesystem doesn't implement hard links
> >> then the LINK request will fail and the lookup count will not be
> >> incremented.
> >>
> >> Thanks,
> >> Miklos
> >
> >
> >



------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Goswin von Brederlow-2
In reply to this post by Stef Bon-2
Stef Bon <[hidden email]> writes:

> Hardlinks are a whole different story.
>
> What do you do when looking up a hardlink, is the number of lookups of
> the target
> of the link also incremented?
>
> S.

Since the lookup is on the inode using either name increments the inodes
lookup count and you get a forget call for the sum of the lookups.

        void (*forget) (fuse_req_t req, fuse_ino_t ino, unsigned long nlookup);

There is no differentiation which name associated to the inode gets
forgotten, only the inode itself.

A hardlink has no target, it is the target.

MfG
        Goswin

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Goswin von Brederlow-2
In reply to this post by Miklos Szeredi
Miklos Szeredi <[hidden email]> writes:

> On Thu, 01 Jul 2010, Paul Schutte wrote:
>> Basically I build in a check in forget to warn me when the reference
>> goes negative. This should never happen.
>> I then caught a few negative references and figured out that when ever
>> you hard link a file, you should increase the reference as well
>> (regardless of the number of lookups that happend)
>> The reference count checks out 100% when you do that.
>
> Right.
>
> More generally, every "creation" also counts as a lookup.
>
> If the creation occured because of MKDIR, CREATE, MKNOD, SYMLINK, then
> the count will be incremented from zero to one.
>
> If the creation was because of a LINK then the count will be
> incremented from N to N+1.
>
> Thanks,
> Miklos

But what he is saying that if LINK is not implemented and creating a
hardlink simply fails the count is also incremented from N to N+1.
Because of that it becomes impossible to implement FORGET without also
providing at least a skeleton LINK that increments the lookup cound and
fails.

At least that is how it sounds to me.

MfG
        Goswin

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Paul Schutte
In reply to this post by Goswin von Brederlow-2
But the hardlink on the inode did not succeed, so it should not
increment it.

If I don't implement hardlinks then my fs has no idea that the inode was
even touched.

On Thu, 2010-07-01 at 15:46 +0200, Goswin von Brederlow wrote:

> Stef Bon <[hidden email]> writes:
>
> > Hardlinks are a whole different story.
> >
> > What do you do when looking up a hardlink, is the number of lookups of
> > the target
> > of the link also incremented?
> >
> > S.
>
> Since the lookup is on the inode using either name increments the inodes
> lookup count and you get a forget call for the sum of the lookups.
>
>         void (*forget) (fuse_req_t req, fuse_ino_t ino, unsigned long nlookup);
>
> There is no differentiation which name associated to the inode gets
> forgotten, only the inode itself.
>
> A hardlink has no target, it is the target.
>
> MfG
>         Goswin
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> fuse-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/fuse-devel



------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Miklos Szeredi
In reply to this post by Paul Schutte
On Thu, 01 Jul 2010, Paul Schutte wrote:
> That is why I say I think I stumbled onto a bug.
> It looks like the lookup count (on the fuse side) does get incremented
> even when the LINK request fails.

I can't reproduce this.  Can you send a test program?

Thanks,
Miklos

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: forget inodes

Paul Schutte
Will do, as soon as I get home. I do the fs stuff in my own time.


On Thu, 2010-07-01 at 16:01 +0200, Miklos Szeredi wrote:
> On Thu, 01 Jul 2010, Paul Schutte wrote:
> > That is why I say I think I stumbled onto a bug.
> > It looks like the lookup count (on the fuse side) does get incremented
> > even when the LINK request fails.
>
> I can't reproduce this.  Can you send a test program?
>
> Thanks,
> Miklos



------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
12