Re: btrfs send yields "ERROR: send ioctl failed with -5: Input/output error"

[Duncan <1i5t5.duncan@cox.net>]

Duncan posted on Mon, 30 Oct 2017 04:09:58 +0000 as excerpted:

> Zak Kohler posted on Sun, 29 Oct 2017 21:57:00 -0400 as excerpted:
> 
>> So I ran memtest86+ 5.01 for >4 days:
>> Pass: 39 Errors: 0
> 
> Be aware that memtest86+ will detect some types of errors but not
> others.
> 
> In particular, some years ago I had some memory (DDR1/3-digit-Opteron
> era), actually registered as required by Opterons and ECC, that passed
> that sort of memory test because what the test /tests/ is memory cell
> retention (if you put a value in does it verify on read-back?), that was
> none-the-less bad memory in that at its rated speed it was unreliable at
> memory /transfers/.
> 
> Eventually that mobo got a BIOS update that could adjust memory
> clocking, and I downclocked it a notch[.] At
> the lower clock it was rock stable, even with reduced wait-states to
> make up a bit of the performance I was losing to the lower clock.  But I
> had to get a BIOS that could do it, first [...]

> That's what really amazed me about reiserfs, that it remained stable
> thru not only that hardware problem but various others I've had over the
> years that would have killed or made unworkable other filesystems.

BTW, one of those other hardware problems I had, the one that ultimately 
did in my old server-clase mobo, was leaky capacitors on the then 8-ish 
years old system.  It was of the generation that had problem capacitors, 
and it eventually succumbed...

The reason this is relevant is that it was the storage path that had the 
worst problems.  Before I figured out what the problem actually was I did 
try btrfs, with around kernel 3.6 at the time, and it really /was/ 
unusable due to checksum errors.  But I could still limp along with 
reiserfs...

One thing about the behavior I noticed, however, was that as the problem 
was developing, the system was more usable if I kept it reasonably cool.  
By the time I gave up on it, it was early summer here in Phoenix, and 
temperatures were climbing.  But I was sitting at home with the AC on, in 
a heavy winter jacket, wearing sweats under my pants and trying to type 
with gloves on my hands to keep warm, in ordered to cool down the 
computer so it'd work.  That's when I decided enough was enough and gave 
up on it.  I only found the burst capacitors, however, once I got the new 
mobo and was switching out the old one.  No WONDER it wasn't working 
right any more!

The rest of the system was actually reasonably stable, however.  I guess 
the worst caps were in the storage path.

But as I said, reiserfs was amazing.  I bought a SATA addon board with 
the same chipset as on the old mobo so I could boot the old monolithic 
kernel with those drivers builtin on the new mobo, and I didn't notice 
any corruption or anything.  But as I said, btrfs was entirely unusable 
on the old hardware, due to both checksum errors and large transactions 
(like trying to copy files over from reiserfs) ending up entirely 
reverted when I'd crash, instead of the partial completion I'd get on 
reiserfs, so I could at least reboot and start where it has crashed on 
reiserfs, instead of having to start over entirely, thus making no 
progress at all, which is what I was seeing on btrfs.

That reiserfs continued to work well enough to keep going so long under 
those conditions, while btrfs was entirely unworkable, and even more that 
once I was running good hardware again, I didn't see massive corruption 
on reiserfs as a result of trying to run it on so long on the bad 
hardware, was really /really/ amazing!

But like I said, I don't expect that btrfs, with its checksumming, with 
/ever/ be really workable on that sort of defective hardware.  It was 
just really amazing to me that reiserfs wasn't screwed up by it as well, 
as it had every right to be given the screwed up hardware I was trying to 
run it on.  No filesystem can be expected to go thru that and end up 
still usable, but somehow, reiserfs did.

Bottom line, it could be the storage path, not the memory or cpu.

-- 
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