Re: CVS commit: src/sys/kern
On Jan 11, 1:48am, y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: -- Subject: 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? Yes, the logging one is purely for debugging, but the first one I use all the time because I don't have critical data one many of my servers and it is a lot faster. I should make them only settable by the superuser I guess. christos
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
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/sbin/disklabel
On Sun, 09 Jan 2011, Izumi Tsutsui wrote: > > Modified Files: > > src/sbin/disklabel: interact.c main.c printlabel.c > > > > Log Message: > > Change printf formats to match the data type of the values being > > printed. There's now a lot of PRIu16 and PRIu32, some PRIu8, some > > SCNu32, and a few cases where %u and %d were reversed. > > Probably you also have to add them (at least PRIu8 and SCNu32) > into tools/compat/compat_defs.h for src/tools/disklabel. OK, done. --apb (Alan Barrett)
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
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. -- David A. Holland dholl...@netbsd.org
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 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
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
