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
