JorgeB

There's also a FAQ entry about that.

Look for a BIOS update and or try the latest Unraid -rc, if that doesn't help not much more you can do other than using different NVMe deiveces or a different board.

Yes, the problem now is the Marvell controller with port multipliers.

To use ddrescue you'd need to clone to a same size device, to keep the partition valid for Unraid.

The way that btrfs reports used/free space was changed recently, main is correct, dashboard probably needs updating, might be good to create a bug report. Note that the free space with an odd number of raid1 devices will be incorrectly reported, but that is a btrfs issue.

I'm more familiar with LSI controllers, but IIRC others users are using that one, still best to search the forum to confirm.

It does.

When is currently? I looked at the beginning of the syslog in the diags, disks 1, 8, 9, 10, 11, 12 and 13 were connected with USB, then they dropped: Jan 15 13:01:40 JEJ-Unraid kernel: usb 2-4: Device not responding to setup address. ### [PREVIOUS LINE REPEATED 1 TIMES] ### Jan 15 13:01:41 JEJ-Unraid kernel: usb 2-4: device not accepting address 2, error -71 Jan 15 13:01:45 JEJ-Unraid kernel: usb usb2-port4: Cannot enable. Maybe the USB cable is bad? ### [PREVIOUS LINE REPEATED 2 TIMES] ### Jan 15 13:01:53 JEJ-Unraid kernel: usb 2-4: USB disconnect, device number 2 Then the disks errors: Jan 15 13:01:53 JEJ-Unraid kernel: md: disk1 write error, sector=4294967280 Jan 15 13:01:53 JEJ-Unraid kernel: md: recovery thread: exit status: -4 Jan 15 13:01:53 JEJ-Unraid kernel: md: disk8 read error, sector=8633241376 Jan 15 13:01:53 JEJ-Unraid kernel: md: disk9 read error, sector=8633241376 Jan 15 13:01:53 JEJ-Unraid kernel: md: disk10 read error, sector=8633241376 Jan 15 13:01:53 JEJ-Unraid kernel: md: disk11 read error, sector=8633241376 Jan 15 13:01:53 JEJ-Unraid kernel: md: disk12 read error, sector=8633241376 Jan 15 13:01:53 JEJ-Unraid kernel: md: disk13 read error, sector=8633241376 Array did change after that, but that part is not covered in the diags due to log spam so we can't really see the problem, reboot and post new diags

Correct, but it's not an Unraid problem, I've had servers booting non UEFI with NVMe devices without issues, but if with UEFI works just boot with that.

That controller is not recommended, you also have several disks connected with USB, that's even worse, and appears to be the main issue currently.

If you mean the UD share this should have been asked in the UD support thread, but it will be under /mnt/remotes

If it can fit on cache it should definitely be there, vdisks on the array will have very bad performance due to parity.

Diags are not available, but did you format the disk after adding to the array?

Is the vdisk on cache or array?

I guess you mean re-format? If that's it then yes, but it can be left in slot, that won't matter, backup cache and re-format, I assume it this post: Looking at the diags there were errors on the remaining device: Jan 20 09:12:47 Unraid-Tower kernel: BTRFS info (device nvme0n1p1): bdev /dev/nvme0n1p1 errs: wr 1314931, rd 1043949, flush 26985, corrupt 1428, gen 0 This suggests that device also dropped offline in the past and it was never corrected, when the other device failed it was corrupt, tell the user to look a look here for better pool monitoring.

Very unlikely that will help.

This issue appears to be fixed.

If the pool was redundant you can have just slot2 populated, if it's not working there are other issues.

Like mentioned it's not a question of being detected, it's being detected but it fails to initialize, NVMe also work using legacy boot, it could be a board issue, possibly just a BIOS issue, BIOS update might help.

Best bet would be to use a disk share for that, instead of a user share, performance of user shares with small files will downgrade a lot.

Yes but the sync errors started before the read errors, so not necessarily a direct connection, though can't never say conclusively one way or the other. #1 is after an unclean shutdown, #2 is due to bad hardware, most commonly bad RAM. Not practical for me, because every couple of weeks or so I move data from my main servers to cold storage servers, which are always off except while receiving the data, so if I moved the data then waited for the checksums to be generated it would take twice as long, also I need the snapshot feature of btrfs since it's what I use to send data to my backup servers. I use the WIndows version, I create the cheskums by folder before sending them to the cold storage servers (but not for everything, only for movies and TV shows), this makes it possible first to confirm the data was correctly sent, like if I ever suspect a network problem, btrfs couldn't help with that since the data would arrive already corrupt, also good for if I just need to check a movie or a TV show, with btrfs I can only do a full disk check, and a TV season can be split over various disks.

If the device has pending sectors the problem is reading, not writing, you can try cloninh it with ddrescue and then use the clone in the pool.

Cache device dropped offline, replace cables to rule them out.

It's not a problem mixing SAS and SATA, as for the link speed you can check it by clicking on the device on the main page.

Is that large or small files? Small files will transfer much slower, try copying a large file to cache.