My parity disc can no longer be mounted after an error

9 minutes ago, Pardasus said:

I'm just wondering why unRAID 6.x partitioned my discs in DOS.

Like mentioned, this is normal for all devices up to 2TB, and that is not the problem, the problem is that the USB enclosure you are using is reporting the device has an SSD, instead of a HDD.

 

You can try manually creating an MBR partition starting on the correct sector for a HDD and that should workaround the problem:

 

- unassign parity

- erase the disk with 

wipefs -a /dev/sdX

- create an MBR partition

sfdisk /dev/sdX

type 64 and hit enter

type write and hit enter

- reassign the disk as parity

I see 5400 rpm under ‘Identity’. And the other discs are also shown as SSD.

 

sda = HDD

sdb = HDD

sdc = HDD

Quote

NAME        ROTA
loop0          1
loop1          1
sda            0
└─sda1         0
sdb            0
└─sdb1         0
sdc            0
└─sdc1         0
sdd            1
└─sdd1         1
sde            1
nvme0n1        0
└─nvme0n1p1    0
nvme1n1        0
└─nvme1n1p1    0
 

Are you sure that this is the problem? The other HDDs are also running. Or does it make a difference with the parity?

 

Unfortunately, partitioning with start sector 64 did not work. The disc still cannot be used as a parity disc 😞

 

Here is a picture of what the system looks like. On the left is the main system and on the right the backup system.

The hard drives are located in a USB-C enclosure which in turn is connected to a USB hub. This hub then goes into the computer on the left via USB-C.

10 minutes ago, Pardasus said:

Are you sure that this is the problem?

Yes, Unraid selects the start sector based on if the device is detected as an SSD (2048) or HDD (64)

 

The other disks are using sector 64, meaning they were detected as HDDs when initially formatted, or they were formatted on an older release, that didn't yet make the distinction, IIRC, that happens since v6.9.

I have now downgraded to 6.12.11 and was able to add the disc as parity without any problems. Now everything is fine again and parity is being restored. After that I can update to 7.x again. But that could be a problem for me in the future. Where and how do I report that I have a problem with 7.x?

here, and you did

Edited August 18 by Kilrah

That suggests it may be the USB UAS driver that is causing the change, first still on 6.12, post the output from:

 

lsblk -o name,rota

 

Than add to syslinux.cfg

 

usb_storage.quirks=174c:235c:u

 

(if you don't know where, click on the flash drive then add to the default boot option after /bzroot, the one in green, e.g.:)

 

 

Then upgrade back to v7, and again post the output from:

 

lsblk -o name,rota

 

It almost looks as if it swaps 0 and 1 in the new driver. 

NAME        ROTA
loop0          1
loop1          1
loop2          0
loop3          1
sda            1
└─sda1         1
sdb            1
└─sdb1         1
sdc            1
└─sdc1         1
sdd            1
└─sdd1         1
sde            1
md1p1          1
md2p1          1
nvme0n1        0
└─nvme0n1p1    0
nvme1n1        0
└─nvme1n1p1    0

 

I will add the rest as soon as the parity is restored.

9 minutes ago, Pardasus said:

It almost looks as if it swaps 0 and 1 in the new driver. 

Yep, with the old USB storage drive it correctly reports HDDs, it's not a general problem with the faster UASP driver used with 7.0, since it still reports a HDD with the enclosure I tested, so likely a problem with the UASP driver and the enclosures you are using, but the kernel option I posted above forces the USB enclosures to use the old USB storage driver instead, so that should solve the problem for you for the future.

 

Just one more reason to avoid USB with the array and pool devices whenever possible.

I don't quite believe in incompatibility. All three drives are in exactly the same USB-C enclosure type. All three HDDs are also of exactly the same type. Only the parity disc was displayed as an SSD. The others were displayed as HDD under 6.12.x as well as under 7.x. 

 

I have run the update to 7.0.0-beta.2 again without using the mitigations=off parameter. Now all HDDs are displayed as SSDs. But the system runs as it did before since the 7 version was released.

NAME        ROTA
loop0          1
loop1          1
loop2          0
loop3          1
sda            0
└─sda1         0
sdb            0
└─sdb1         0
sdc            0
└─sdc1         0
sdd            1
└─sdd1         1
sde            1
md1p1          1
md2p1          1
nvme0n1        0
└─nvme0n1p1    0
nvme1n1        0
└─nvme1n1p1    0

 

I can set the parameter at any time, as I understand it. So I'll leave it like this for now. But I'll try something else on my test system in parallel and get back to you.

 

 

Quote

Just one more reason to avoid USB with the array and pool devices whenever possible.

That may be, but then it doesn't look as cool as in my photo

2 hours ago, Pardasus said:

All three drives are in exactly the same USB-C enclosure type. All three HDDs are also of exactly the same type. Only the parity disc was displayed as an SSD.

No, all three disk are reported as SSDs, you were having the issue with parity because that's the disk you were adding to the array, if you were trying to replace disk1 or disk2, you would have the exact same same problem.

 

2 hours ago, Pardasus said:

I can set the parameter at any time, as I understand it. So I'll leave it like this for now.

Yes, that a good workaround.

I have looked into the subject further, as I had no idea about it. According to the manufacturer of my HDD enclosure, the UASP protocol should be supported. If the manufacturer explicitly advertises this, why is it not recognised correctly? Do you have any ideas?

 

https://de.ugreen.com/products/ugreen-2-5-zoll-festplattengehause-usb-3-0-externes-gehause-uasp-usb-3-0-festplatte-gehause-fur-2-5-zoll-sata-ssd-und-hdd-in-hohe-9-5mm-7mm-usb-case-mit-usb-3-0-kabel-werkzeugfreie-montage?_pos=2&_sid=48f2dd29a&_ss=r

14 minutes ago, Pardasus said:

the UASP protocol should be supported. If the manufacturer explicitly advertises this, why is it not recognised correctly?

UASP is supported, or they wouldn't work, but it's identifying the devices as SSDs, instead of HDDs, possibly a firmware bug.