Valentin Hilbig

Thanks, USB is probably the best pointer to look at. As there are USB issues .. always. Note that I have over 30 USB disks splitted onto 4 different USB-3 paths on different IO controller cards and different external enclosures .. Some are ZFS, most are SnapRAID .. I'd like to move to iSCSI, but the problem is that 10 GBit/s Ethernet is a bit too slow on the long term and nobody can pay 40 GBit/s ethernet today. So perhaps sometimes in future USB-3.2 Computer-Computer connection (with Ethernet transport)...

I have exactly the same issue but have no real idea yet where it comes from. At my side: The problem shows up quite often (read: more than 2 times a quarter), especially when running longer SnapRAID jobs. It does not show up "reliably", so I cannot reproduce it on will. It often shows up in the 3rd "content" file. Note that I have 13 content files currently. (I did not test the other content files yet when it occurs, only the reported one) I have no ECC, but all memory tests are OK (including kernel...

BTW: a successful snapraid sync fixed the issue at my side.

BTW: snapraid diff shows No differences (but the - broken - sync was due to some files were deleted)

No, I do not need help (at this step)! But perhaps this helps to improve SnapRAID. Currently I have a very similar but different problem to those "cannot fix" problems. Perhaps all might have the same cause? snapraid status complains bad blocks after a sync went downhill. snapraid check tells, that everything is OK snapraid fix tells, that there is nothing to do. snapraid scrub tells, that there are parity errors. Apparently there is some internal logic error in how "transient bad blocks" are handled....

PLEASE DELETE THIS THREAD. As I cannot edit the topic, this thread is DEAD. Again: WTF, how bad can a forum software be ..

PLEASE IGNORE EVERYTHING ABOVE, RESTARTING FROM SCRATCH (WTF is this a bad forum software!)

I did not post this. My browser misbehaved. And it does not allow me to edit or delete it.