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    [W:0.031 / U:0.124 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site