Re: CVS commit: src
On Mon, Jan 10, 2011 at 11:11:04AM +, Juergen Hannken-Illjes wrote: Module Name: src Committed By: hannken Date: Mon Jan 10 11:11:04 UTC 2011 Modified Files: src/sys/miscfs/genfs: layer_extern.h layer_vnops.c src/sys/miscfs/nullfs: null_vnops.c src/sys/miscfs/overlay: overlay_vnops.c src/sys/miscfs/umapfs: umap_vnops.c src/tests/fs/ptyfs: t_nullpts.c Log Message: Add layer_revoke() that adjusts the lower vnode use count to be at least as high as the upper vnode count before passing down the VOP_REVOKE(). This way vclean() check for active (vp-v_usecount 1) vnodes gets it right. Randomly changing v_usecount sounds bogus to me? Probably hiding some other bug somewhere else. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src
On Mon, Jan 10, 2011 at 06:25:16PM +, David Laight wrote: On Mon, Jan 10, 2011 at 11:11:04AM +, Juergen Hannken-Illjes wrote: Module Name:src Committed By: hannken Date: Mon Jan 10 11:11:04 UTC 2011 Modified Files: src/sys/miscfs/genfs: layer_extern.h layer_vnops.c src/sys/miscfs/nullfs: null_vnops.c src/sys/miscfs/overlay: overlay_vnops.c src/sys/miscfs/umapfs: umap_vnops.c src/tests/fs/ptyfs: t_nullpts.c Log Message: Add layer_revoke() that adjusts the lower vnode use count to be at least as high as the upper vnode count before passing down the VOP_REVOKE(). This way vclean() check for active (vp-v_usecount 1) vnodes gets it right. Randomly changing v_usecount sounds bogus to me? This is not a random change. Layered file systems take exactly one reference on the lower vnode. All references regarding layered vnodes are only taken on the layer vnode. So we get a bootom vnode that is active (we are working on it) while it may have just one reference. The upper (layer) vnode has the valid reference count. Now when VOP_REVOKE() goes down the stack it will revoke the lowest vnode but this vnode looks inactive. Adjusting the lower vnode refcount gets the (in respect to activity) right usecount on the lowest vnode while VOP_REVOKE() works on the lowest vnode. Probably hiding some other bug somewhere else. David -- David Laight: da...@l8s.co.uk -- Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Re: CVS commit: src/etc/mtree
On Mon, Jan 10, 2011 at 05:17:37PM +, Nicolas Joly wrote: Module Name: src Committed By: njoly Date: Mon Jan 10 17:17:36 UTC 2011 Modified Files: src/etc/mtree: NetBSD.dist.tests Log Message: Add lib/libc/sys test dirs. Thanks! Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: CVS commit: src
On Mon, Jan 10, 2011 at 07:33:40PM +, David Holland wrote: On Mon, Jan 10, 2011 at 07:38:22PM +0100, Juergen Hannken-Illjes wrote: This is not a random change. Layered file systems take exactly one reference on the lower vnode. All references regarding layered vnodes are only taken on the layer vnode. So we get a bootom vnode that is active (we are working on it) while it may have just one reference. The upper (layer) vnode has the valid reference count. Now when VOP_REVOKE() goes down the stack it will revoke the lowest vnode but this vnode looks inactive. Adjusting the lower vnode refcount gets the (in respect to activity) right usecount on the lowest vnode while VOP_REVOKE() works on the lowest vnode. As far as I can tell it only uses the usecount to decide whether the vnode is still active or not, so adding 1 temporarily should be sufficient if the goal is to have it not disappear. OTOH, it seems to me that it *should* disappear in that case, and also that vrevoke() should also end up getting called on the layer vnode. What about other references to the 'lower' vnode? If the revoke of the lower vnode is done one for each reference of the layer vnode - then you need to add 'n - 1' to the ref count of the lower vnode, not set it to 'n'. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/kern
hi, Module Name: src Committed By: christos Date: Sat Jan 8 20:37:05 UTC 2011 Modified Files: src/sys/kern: vfs_wapbl.c Log Message: Add two sysctls one that does verbose transaction logging and a second one that disables flushing the disk cache (which is fast but dangerous for data integrity). From simon a long while back. i don't think this kind of knob should be system global. are they merely for debug? YAMAMOTO Takashi To generate a diff of this commit: cvs rdiff -u -r1.38 -r1.39 src/sys/kern/vfs_wapbl.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/tests/fs/common
hi, On Thu, Jan 06, 2011 at 12:53:28AM +, YAMAMOTO Takashi wrote: (one nfsro test currently fails with EROFS vs. EACCES. Hopefully someone else can debate the correct errno) the NFS ACCESS procedure, which is used for open time permission checks, does not have a way to distinguish EROFS and EACCES. ie. EACCES is the expected behaviour in this case. Shouldn't the nfs client know that it's supposed to be readonly? probably. please feel free to fix it. :-) however, Or is this a case where the nfs client is read-write but the server isn't? i think so, yes. in this case, the client can't know EROFS at open time. YAMAMOTO Takashi -- David A. Holland dholl...@netbsd.org
