Re: multiple vnodes for same file?
On Sun, Jul 01, 2012 at 04:05:58AM +0200, Emmanuel Dreyfus wrote: > In perfuse, I attempt to reuse the same userland puffs node when the > same file is looked up. I do that by searching an inode number match > accross siblings. > > I experience unleasant things such as INACTIVE after RECLAIM on the same > puffs node, which cause crashes since RECLAIM releases ressources > associated with the node. > > I suspect this is because the kernel used two different vnodes for the > same file. The different vnodes being represented by the same puffs node > in libperfuse, that can explain I still get activity after RECLAIM. Is > that possible? Is it sane behavior to use two vnodes for the same file > at once, or is that a bug in kernel part of puffs? It should not happen; if it does, something is badly wrong somewhere. There are various moderately bogus things that go on with device vnodes, though; are the vnodes making trouble devices? -- David A. Holland dholl...@netbsd.org
Re: multiple vnodes for same file?
hi, > Hi > > In perfuse, I attempt to reuse the same userland puffs node when the > same file is looked up. I do that by searching an inode number match > accross siblings. > > I experience unleasant things such as INACTIVE after RECLAIM on the same > puffs node, which cause crashes since RECLAIM releases ressources > associated with the node. > > I suspect this is because the kernel used two different vnodes for the > same file. The different vnodes being represented by the same puffs node > in libperfuse, that can explain I still get activity after RECLAIM. Is > that possible? Is it sane behavior to use two vnodes for the same file > at once, or is that a bug in kernel part of puffs? it isn't a sane behaviour. i want to see the log. YAMAMOTO Takashi > > -- > Emmanuel Dreyfus > http://hcpnet.free.fr/pubz > m...@netbsd.org
Re: multiple vnodes for same file?
YAMAMOTO Takashi wrote: > it isn't a sane behaviour. > i want to see the log. I found the bug in kernel part of PUFFS, and I am the one that introduced it: if I get a vnode from name cache and succesfully lookup it, I reuse the cached vnode without checking if the userland cookie matches. Fix coming soon. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: multiple vnodes for same file?
> YAMAMOTO Takashi wrote: > >> it isn't a sane behaviour. >> i want to see the log. > > I found the bug in kernel part of PUFFS, and I am the one that > introduced it: if I get a vnode from name cache and succesfully lookup > it, I reuse the cached vnode without checking if the userland cookie > matches. Fix coming soon. i don't understand. name cache is looked up with (parent vnode, component name). why and how do you check the userland cookie? YAMAMOTO Takashi > > -- > Emmanuel Dreyfus > http://hcpnet.free.fr/pubz > m...@netbsd.org
Re: multiple vnodes for same file?
On Mon, Jul 02, 2012 at 05:21:24AM +, YAMAMOTO Takashi wrote: > i don't understand. > name cache is looked up with (parent vnode, component name). > why and how do you check the userland cookie? This is how it works: - check cname ache - if cache hit with valid TTL, return result - perfom lookup, get userland cookie - call puffs_cookie2vnode() to retreive existing vnode - if it exists, return it, otherwise create a new vnode The bug is that puffs_cookie2vnode() is not called if wre have cache hit AND expired TTL AND successful lookup, and I use the vnode from cache regardless if it is matching userland cookie. -- Emmanuel Dreyfus m...@netbsd.org
Re: multiple vnodes for same file?
hi, > On Mon, Jul 02, 2012 at 05:21:24AM +, YAMAMOTO Takashi wrote: >> i don't understand. >> name cache is looked up with (parent vnode, component name). >> why and how do you check the userland cookie? > > This is how it works: > - check cname ache > - if cache hit with valid TTL, return result > - perfom lookup, get userland cookie > - call puffs_cookie2vnode() to retreive existing vnode > - if it exists, return it, otherwise create a new vnode > > The bug is that puffs_cookie2vnode() is not called if wre have > cache hit AND expired TTL AND successful lookup, and I use > the vnode from cache regardless if it is matching userland cookie. while an expired TTL means puffs can consult userland, it doesn't mean the vnode associated to the cache entry can be stale (reclaimed), does it? YAMAMOTO Takashi > > -- > Emmanuel Dreyfus > m...@netbsd.org
Re: multiple vnodes for same file?
On Mon, Jul 09, 2012 at 05:31:32AM +, YAMAMOTO Takashi wrote: > while an expired TTL means puffs can consult userland, it doesn't > mean the vnode associated to the cache entry can be stale (reclaimed), > does it? Yes, you are right. I fixed that part but found other problems in the meantime, and I am sill refactoring the code. There are many bugs hidden in perfuse around reclaim, but they have been hidden for now since vnodes were reclaimed very late, when the kernel ran out of vnodes. In order to save memmory, I wrote code to reclaim vnodes a bit earlier, and this opened a can of worms. Here is an example on which I stuggle right now: - lookup a in / - lookup b in a - reclaim a - lookup .. in b -> this is a, but I forgot its name. I also have a problem to reference its parent. - lookup a in / -> now I must reconnect b/.. and /a since they are the same node. That suggests that each time I lookup a node, I must walk all nodes known to perfused to check that it was not already known with same inode, but with another name (e.g.: "b" vs ".."). I must also modify the parent when reconnecting ".." to a named node. Another approach could be to refrain the kernel from reclaiming vnodes that still have children. It seems much simplier. -- Emmanuel Dreyfus m...@netbsd.org
Re: multiple vnodes for same file?
On Mon, Jul 09, 2012 at 06:10:14AM +, Emmanuel Dreyfus wrote: > Here is an example on which I stuggle right now: > - lookup a in / > - lookup b in a > - reclaim a > - lookup .. in b > -> this is a, but I forgot its name. I also have a problem to reference its > parent. > - lookup a in / > -> now I must reconnect b/.. and /a since they are the same node. > > That suggests that each time I lookup a node, I must walk all nodes > known to perfused to check that it was not already known with same > inode, but with another name (e.g.: "b" vs ".."). I must also modify > the parent when reconnecting ".." to a named node. I don't know what the data structures involved look like, but what you say suggests they're wrong. "a" and "b/.." have the same inode number, and you should therefore naturally get the same object back from lookup. > Another approach could be to refrain the kernel from reclaiming vnodes > that still have children. It seems much simplier. That is a can of worms. -- David A. Holland dholl...@netbsd.org
Re: multiple vnodes for same file?
On Mon, Jul 09, 2012 at 06:48:20PM +, David Holland wrote: > I don't know what the data structures involved look like, but what you > say suggests they're wrong. "a" and "b/.." have the same inode number, > and you should therefore naturally get the same object back from > lookup. Yes, I am working on fixing it. -- Emmanuel Dreyfus m...@netbsd.org
Re: multiple vnodes for same file?
On Mon 09 Jul 2012 at 06:10:14 +, Emmanuel Dreyfus wrote: > Another approach could be to refrain the kernel from reclaiming vnodes > that still have children. It seems much simplier. Back in the day when I wrote MSH: (a MSDOS filesystem for the Amiga), I think I did that. (Locks on) Directories refer to (Locks on) their parents, so therefore they contribute to their refcount. Open files own a Lock too, which also refers to its parent directory (Lock), and which therefore also contributes to its refcount. It seems that an AmigaOS Lock is comparable with a vnode. > Emmanuel Dreyfus -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: multiple vnodes for same file?
On Mon, Jul 09, 2012 at 07:10:00PM +, Emmanuel Dreyfus wrote: > > I don't know what the data structures involved look like, but what you > > say suggests they're wrong. "a" and "b/.." have the same inode number, > > and you should therefore naturally get the same object back from > > lookup. > > Yes, I am working on fixing it. ok then :-) -- David A. Holland dholl...@netbsd.org
