Btrfs devel - Mar 2008 - Checksum verify failed on btrfs-unstable.

Hi.

During stress iozone test I got folowing in the dmesg:
btrfs: sdb1 checksum verify failed on 339968 wanted 0 found 4DF48705
from_this_trans 0
btrfs: sdb1 checksum verify failed on 2416152576 wanted 652FF515 found 33873956
from_this_trans 0
btrfs: sdb1 checksum verify failed on 2416205824 wanted 0 found 8A564C6F
from_this_trans 0
btrfs: sdb1 checksum verify failed on 2416201728 wanted 0 found 483BDD7A
from_this_trans 0
btrfs: sdb1 checksum verify failed on 2416291840 wanted 7F9C20D5 found 37743979
from_this_trans 0
btrfs: sdb1 checksum verify failed on 2416295936 wanted 52EC324B found 3EC198D9
from_this_trans 0
btrfs: sdb1 checksum verify failed on 3221446656 wanted E07513DE found CE09AC12
from_this_trans 0
btrfs: sdb1 checksum verify failed on 3221278720 wanted A8066EF9 found C0AFDE27
from_this_trans 0
btrfs: sdb1 checksum verify failed on 3221565440 wanted 3565A941 found 32B5AA6C
from_this_trans 0
btrfs: sdb1 checksum verify failed on 3221581824 wanted 40273FB3 found 4403DB2F
from_this_trans 0
btrfs: sdb1 checksum verify failed on 3221602304 wanted D7153349 found 22343E06
from_this_trans 0

Performance degraded to hell for this test (8gb file, automatic iozone mode,
probably during
random read test).

Filesystem was made with -l 4k -n 4k options and mounted with
noatime,nodatasum,ssd options.

Single 266 gb scsi disk.
Any additional details?

-- 
	Evgeniy Polyakov

On Monday 24 March 2008, Evgeniy Polyakov wrote:
> Hi.
>
> During stress iozone test I got folowing in the dmesg:
> btrfs: sdb1 checksum verify failed on 339968 wanted 0 found 4DF48705
> from_this_trans 0
These are harmless for now, there is a small window where a buffer can change 
while it is being written (making the csum invalid).  It is slated to be 
fixed after the multi device code goes in.
>
> Performance degraded to hell for this test (8gb file, automatic iozone
> mode, probably during random read test).
I'd have to see all the test details to explain performance problems.  I
would
expect that once you do a series of random writes to the file, sequential 
reads are going to be painfully slow.  For that kind of database workload, 
you'll want to mount with -o nodatacow.  Since iozone lays out the file once
in the beginning, performance will definitely suffer after it does a random 
write run.
>
> Filesystem was made with -l 4k -n 4k options and mounted with
> noatime,nodatasum,ssd options.
>
> Single 266 gb scsi disk.
> Any additional details?
The ssd mount option assumes that reads are seek free.  It will be optimal for 
postmark, which only does random reads and never does sequential reads, but 
it will be slower for most other benchmarks.

-chris