Austin S. Hemmelgarn posted on Mon, 09 May 2016 14:21:57 -0400 as excerpted: > This practice evolved out of the fact that the only bad RAM I've ever > dealt with either completely failed to POST (which can have all kinds of > interesting symptoms if it's just one module, some MB's refuse to boot, > some report the error, others just disable the module and act like > nothing happened), or passed all the memory testing tools I threw at it > (memtest86, memtest86+, memtester, concurrent memtest86 invocations from > Xen domains, inventive acrobatics with tmpfs and FIO, etc), but failed > under heavy concurrent random access, which can be reliably produced by > running a bunch of big software builds at the same time with the CPU > insanely over-committed. My (likely much more limited) experience matches yours. Tho FWIW, in my case I did find that one of the more common memory failure indicators was bz2-ed tarball decompression, where the tarball would fail its decompression checksum safety checks. However, that most reliably happened in the context of a heavily loaded system doing other package builds in parallel to the package tarball extraction that failed. In my case, I even had ECC RAM, but it was apparently just slightly out of spec for its labeled and internally configured memory speeds (PC3200 DDR1 at the time), at least on my hardware. Once I got a BIOS update that let me, I slightly downclocked the memory (to PC3000, IIRC), and it was absolutely solid, no more errors, even with tightened up wait-state timings. Later I upgraded RAM, and the new RAM worked just fine at the same PC3200 speeds that were a problem for the older RAM. The problem was apparently that while the RAM cells that memcheck checks were fine, it was testing in an otherwise calm environment (not much choice since you can only boot to the test directly and can't do anything else at the same time), without all the other stuff going on in the hectic environment of a multi-package parallel build, that apparently happened to occasionally trigger the edge-case that would corrupt things. And FWIW, I still have major respect for how well reiserfs behaved under those conditions. No filesystem can be expected to be 100% reliable when it's getting corrupted data due to bad memory, but reiserfs held up remarkably well, far better than btrfs did under similar conditions (but then with the PCI and SATA bus) a few year later, forcing me back to reiserfs for a time, which again, continued to work like a champ, even under hardware conditions that were absolutely unworkable with btrfs. I had a heat-related (AC went out, in Phoenix, in the summer, 40+ C outside, 50+C inside, who knows what the disks were!?) head crash on a disk too, where the partitions that were mounted and likely had the head flying over them were damaged beyond (easy) recovery, but other partitions on the same disk were absolutely fine, and I actually continued to run off them for a few months after cooling everything back down. That sort of experience is the reason I still use reiserfs on spinning rust, including my second and third level backups, even while I'm running btrfs on the ssds for the working system and primary backup. It's also the reason I continue to use a partitioned system with multiple independent filesystems (btrfs raid1 on a pair of ssds for most of the working btrfs and primary backups, individual ssd btrfs in dup mode for /boot, and its backup on the other ssd), instead of putting my data eggs all in the same filesystem basket with subvolumes, where if the filesystem goes out all the subvolumes go with it! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
