>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: