[lkml]   [2007]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Data corruption
    Hi, thank you for your answer, actually I removed 2Gb of physical memory and 
    the problem gone away .. but my system needs 4Gb.

    I reproduce it under Xen and without xen (on a standard kernel) I can't tell
    you how mutch difference I have betwwen files, regarding a 4 month system
    running on these condition, I think the number of errors are rare but
    existing, during my tests with 100M files I did not get a lot of error, so we
    can assume 2 or 3 bytes in error in 300M files... (expectation)

    I try to avaoid it by disabeling memory relocation on my MB ... in that case
    the system only detect 2.8G (and Linux too), The probem still there.

    It seems to be based on an Asus P5B-VM problem as this one have a lot of with
    4Gb... But it should be certified on Windows up to 8Gb... (but I did not have
    that strange OS to check). So a workaround should exists.

    Le mercredi 8 août 2007 01:57, vous avez écrit :
    > paul wrote:
    > > Since 2-3 month I have some random data corruption on my Linux server,
    > > after checking disks independently (i'm using raid1on 2 sata disk, the
    > > problem is the same w/o raid) and memory, hardware simce to be out of
    > > cause...
    > >
    > > Here is my problem:
    > > => head --bytes=300m /dev/urandom > test
    > > => for i in `seq 0 9` ; do cp test test$i ; done
    > > => md5sum test*
    > > I got :
    > > 014666c728c9e3b8299579fae499864a test
    > > 014666c728c9e3b8299579fae499864a test0
    > > 333fd93d093ac612cd8d5f65628f734e test1
    > > 1ab6ee68c6a7d9ff5a05f9d63f0f6df6 test2
    > > 96e96483e3175a59c9c05b6720514e1e test3
    > > 014666c728c9e3b8299579fae499864a test4
    > > b24dbccc9f4831f8825ab4a55a3be4aa test5
    > > 8493efc9c14e4b5c162ac23696fbc16a test6
    > > 6a5f4301f66d0379049d79d0e14e2a87 test7
    > > 2c81cfa1c3a03aba134574922ee5d75c test8
    > > 2ea15c8392bfd0123472a80125bb3abe test9
    > >
    > > ^^^ that sounds really bad for my data :(
    > It does indeed. Can you try comparing the data to see precisely how much
    > differs between the versions? md5sums don't distinguish between a
    > single-bit error and a block or page-sized error, but the distinction is
    > critical in determining what broke.
    > Can you reproduce this on a recent upstream baremetal (non-Xen) kernel? If
    > so, does it go away when you boot with mem=3000M?
    > -- Chris

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-08-08 08:35    [W:0.025 / U:9.656 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site