novirium

Okay, excellent - that sounds like nothing is actually wrong with my hardware then. The array seems to have been fine once it rebuilt the (badly formatted) drive from parity, so I assume this is something that is down at the disk access level, and not a problem present in the emulated drive? As such, allowing it to rebuild the drive repairs the problem introduced by the bug? I'll keep in mind manually wiping any other new drives first. Thanks for the help 👍

Hi, 3 times now I've had new drives seemingly fail to format when adding them to the array. Each time the process seems to be the same: Stop array Add new drive Clear new drive Clearing finishes - tick the option to confirm I want to format - format new drive Array appears to all be working As soon as I next stop the array, the new drive lists as "wrong" Once this happens, using "xfs_repair -n /dev/sdc1" indicates the filesystem isn't present: Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... .found candidate secondary superblock... unable to verify superblock, continuing... (followed by a bunch of repeating dots) Allowing the drive to rebuild seems to work (though obviously takes ages), and after that point I'm successfully able to use the drive in the array. I did note the "Buffer I/O error on dev md4p1" in the log - and I'd suspect something is wrong with the drive, except this exact same sequence has happened with 3 different drives now as I've added them to the array. This time I stopped the array shortly after the format finished just to check if the problem would occur again before I wrote anything else to the drive (and it did). The rebuild process seems to result in working array, but now I'm getting paranoid something else is going wrong and I'm at risk of losing data I put on to it. Any ideas? Thanks flint-diagnostics-20240116-0955.zip flint-smart-20240116-0958.zip