>Number:         16570
>Category:       kern
>Synopsis:       vnd over NFS loses in some cases
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 29 20:26:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Allen Briggs
>Release:        NetBSD 1.5ZC
>Organization:
	Wasabi Systems, Inc.
>Environment:
System: NetBSD firecat.ninthwonder.com 1.5ZC NetBSD 1.5ZC (GENERIC) #0: Thu Apr 18 10:04:36 EDT 2002 briggs@firecat.ninthwonder.com:/e/netbsd/current/clean/src/sys/arch/i386/compile/GENERIC i386
Architecture: i386,macppc,mips at least
>Description:
	When a vnd is configured with an NFS-backed file, access to the raw
	vnd device fails in some fashion.  A simple way to view this is
	with the newfs command.
>How-To-Repeat:
	In an NFS-mounted directory, run:
	# dd count=4 bs=1m if=/dev/zero of=filesys
	# vnconfig -c vnd0 filesys
	# newfs /dev/rvnd0c
	# newfs /dev/vnd0c
	# newfs /dev/rvnd0c
	# vnconfig -u vnd0

	The first newfs will return an error: "cg 0: bad magic number"
	The second newfs will work, and the third newfs will also work.
	If the second newfs is not present, any number of accesses to
	the raw device will fail.

	Another simple test:
	# dd < /dev/zero > filesys count=10000
	# vnconfig -c vnd0 filesys
	# echo Hello > /dev/rvnd0c
	# hexdump -C -n 16 < /dev/rvnd0c
	# hexdump -C -n 16 < /dev/vnd0c
	# echo There > /dev/vnd0c
	# hexdump -C -n 16 < /dev/rvnd0c
	# hexdump -C -n 16 < /dev/vnd0c
	# echo You Guys > /dev/rvnd0c
	# hexdump -C -n 16 < /dev/rvnd0c
	# hexdump -C -n 16 < /dev/vnd0c
	# vnconfig -u vnd0

	I've seen two different types of output here.  Either I get all zeros
	back, or I get zeros for the first two hexdumps and "There\n" for the
	last 4.  So it seems to me that writes to the raw device are not
	getting flushed somehow and also sometimes the writes to the block
	device are not getting flushed.  In fact, it seems that it flips
	back and forth between the two outputs on successive runs...  Weird.

	OK.  If I insert another write to rvnd0 and another write to vnd0
	(in that order), I see consistent behavior where the last write to
	vnd0 is all that appears in subsequent hexdumps.  If I add more, it
	gets weird again.
>Fix:
	No idea at the moment.
>Release-Note:
>Audit-Trail:
>Unformatted: