lkml.org 
[lkml]   [1997]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectErroneous data with ext2fs
From
Date
Hi there!

*Abstract*:

On a block device (blocksize 1024 bytes) with ext2fs, I don't reliably
get back from a file what I first wrote in.

*Long story*:

I have a block device with 637041 blocks, 1024 bytes per block (it's a
magneto-optical drive). The following tests were made with 4096 bytes
per inode, if that makes any difference. I'm currently running
Linux 2.0.29; earlier versions show the same behaviour.

I noticed this when I first used my mo-drive with ext2. As I am
cautious, I checked all files that I put onto the new drive, and there
were checksum errors reported by gzip.
I then checked the media (the mo-disk) via badblocks with write
enabled (does 4 write/read passes with different patterns) on the
device. No errors. Then I tested xiafs: no errors (I use xiafs on that
device for some months now without any problems).

A simple way of showing the error is to "cat /dev/zero >
/mnt/mo-drive/testfile" and then do some
"cmp -l /mnt/mo-drive/testfile /dev/zero" (sequentially).

Numbers of cmp errors for 19 tries:

run-01: 767
run-02: 767
run-03: 1
run-04: 4255
run-05: 3932
run-06: 0
run-07: 0
run-08: 0
run-09: 1
run-10: 3489
run-11: 0
run-12: 0
run-13: 3487
run-14: 2031
run-15: 2721
run-16: 4
run-17: 1704
run-18: 0
run-19: 769

First few lines of output during run-04):

decimal | octal
514297317 2 0
514297318 200 0
525807617 206 0
525807618 41 0
525807619 10 0
525807621 207 0
525807622 41 0
525807623 10 0
525807625 210 0
525807626 41 0
525807627 10 0
525807629 211 0
525807630 41 0
525807631 10 0
525807633 212 0
525807634 41 0
525807635 10 0
525807637 213 0
525807638 41 0
525807639 10 0
525807641 214 0
525807642 41 0
525807643 10 0
525807645 215 0
525807646 41 0
525807647 10 0
525807649 216 0
525807650 41 0
525807651 10 0

As you may notice, from 525807618 on, it looks like a 4-byte integer in
lsb order which counts up.

Another analysis of the cmp-results shows:

> cat run-01 run-02 | awk '{print $1}' | sort -n | uniq | wc
1534 1534 15340

Although run-01 and run-02 showed the same number of errors, they
occured at different places.

Next analysis:

> cat run-* | sort -n
489283928 14 0
514297317 2 0
514297317 2 0
514297318 200 0
514297318 200 0
514749549 20 0
...
525807842 41 0
525807842 41 0
525807842 41 0
525807842 41 0
525807842 41 0
525807843 10 0
525807843 10 0
525807843 10 0
525807843 10 0
525807843 10 0
525807845 277 0
525807845 277 0
525807845 277 0
525807845 277 0
525807845 277 0
525807846 41 0
525807846 41 0
525807846 41 0
525807846 41 0
525807846 41 0
525807847 10 0
525807847 10 0
525807847 10 0
525807847 10 0
525807847 10 0
525807849 300 0
525807849 300 0
525807849 300 0
525807849 300 0
525807849 300 0
...

This seems to indicate that *if* the read data is false, the false
data is consistent. This also shows that errors do not occur on the
beginning of the filesystem.

Well, I hope somebody fixes this...

If that somebody needs additional info, please contact me.

Leo

\
 
 \ /
  Last update: 2005-03-22 13:39    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site