kern/73579: data corruption on striped geom_vinum volume
Stijn Hoop
stijn at win.tue.nl
Fri Nov 5 12:20:42 PST 2004
>Number: 73579
>Category: kern
>Synopsis: data corruption on striped geom_vinum volume
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Nov 05 20:20:41 GMT 2004
>Closed-Date:
>Last-Modified:
>Originator: Stijn Hoop
>Release: FreeBSD 6.0-CURRENT i386
>Organization:
>Environment:
System: FreeBSD 6.0-CURRENT #0: Fri Nov 5 12:50:21 CET 2004
>Description:
I'm seeing data corruption on a freshly created striped geom_vinum volume,
with a fresh -CURRENT. Verification of the same file yields different
checksums:
[stijn at pcwin002] </local/storage> md5 testfile
MD5 (testfile) = 1af4c4d4bd34128548f9052327bfc717
[stijn at pcwin002] </local/storage> md5 testfile
MD5 (testfile) = 208118b38cd382c2273f00f26a1f3c73
>How-To-Repeat:
- create a striped geom_vinum volume. The fresh test was done with this
configuration file:
%%%
drive meg device ad4s1e
drive herc device ad6s1e
volume storage
plex org striped 479k
sd len * drive meg
sd len * drive herc
%%%
but my initial volume that exhibited the problem had a stripe size of 279k.
- newfs with default paramaters + softupdates
- create a (large) testfile, I used
sudo dd if=/dev/urandom of=testfile bs=1m count=1024
- create a checksum, twice, and witness the result above. Note how the
checksums differ even though no process has since written to or modified
the file.
Drives are fine, checksumming data read from the raw device consistently gives
the same result.
>Fix:
n/a
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-bugs
mailing list