On Fri, 2008-02-15 at 16:59 -0600, Richard Todd wrote: > Bit of a long story behind this one: I've been playing with the "picard" > program in ports to do re-tagging of audio (mp3/ogg) files, and was having > problems with the tagging process creating corrupted .ogg files. On > further investigation trying to debug this, I found that the "picard" > program seemed to be correctly writing the files if I checked them > immediately, but the files were corrupt when I looked at them later. > Further investigation and coming up with test cases brought me to the > surprising conclusion that ZFS was to blame -- under certain conditions ZFS > seems not to be writing all the data in the file out to disk correctly. > The file appears to be good only so long as the file's data is in cache, but > the data actually on disk doesn't match what's in cache. I don't currently have a system that I can test this with, but is there any chance you could make the following change to your script? #!/bin/sh NAME=$1 LEN=$2 rm $NAME ./a.out $NAME $LEN ./gen2.py $NAME md5 $NAME + cp $NAME /some/ufs/filesystem/$NAME.1 ls -l $NAME sudo umount /u3 sudo mount -t zfs u3 /u3 md5 $NAME + cp $NAME /some/ufs/filesystem/$NAME.2 ls -l $NAME + md5 /some/ufs/filesystem/$NAME.? and when you find files that differ, compare the two copies stored on the UFS filesystem with cmp(1)? I'd be interested to know exactly what the corruption looks like - is a single bit differen? Or was an entire page destroyed? Gavin GavinReceived on Mon Feb 18 2008 - 18:08:12 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:27 UTC