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