Jump to content

  • My parity disc can no longer be mounted after an error

    Pardasus

    By Pardasus

      • Minor

    Hello everyone,
    My parity disc had an error. I then removed it from the array. I then checked it for errors and ran a PreClean. The drive seems to be perfectly fine. Now I want to use it as a parity disc again, but the system is telling me that it is not the right size disc.

     

    This is my parity disc:
    2,000,398,934,016 bytes [2.00 TB].

     

    And these are the other discs:
    2,000,398,934,016 bytes [2.00TB].

     

    The exact message is:
    Stopped. The parity disc is not the largest.

    I have already turned the system off and on and erased and formatted the hard drive several times. But the system no longer wants to use this disc as the parity disc. Is this now a bug in 7.0.0 Beta 2?

    smarthomeserver-diagnostics-20240816-0817.zip

    Go to reports Prereleases

    User Feedback

    Recommended Comments



    JorgeB

    That is because parity has an existing smaller partition, erase the disk (click on parity and then erase) and try again.

    Link to comment
    Pardasus

    I have already done this, without success. The system continues to say that the disc is not suitable.

    image.png.58b805e74009f0ba99993d77043258df.png

    Link to comment
    JorgeB

    Did you unassign and reassign the disk after doing that?

     

    If yes post the output of: 

    fdisk -l /dev/sdc

     

    Link to comment
    Pardasus

    @JorgeB

    I have already tried this, also without success.

    Quote

    Disk /dev/sdc: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
    Disk model: SPZX-22UA7T0
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
     

    And from sdb

    Quote

    Disk /dev/sdb: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
    Disk model: SPZX-22UA7T0
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
     

    @ChatNoir

    Do you know this behaviour from the 6.x version? Or how do you know that this is not a bug in 7.0.0-beta.2?

    Edited by Pardasus
    Link to comment
    JorgeB

    The old partition is still being detected, try rebooting.

     

    2 hours ago, Pardasus said:

    And from sdb

    Is this disk1? That one must have a partition.

    Link to comment
    Pardasus

    Not only did I restart the system, I also completely disconnected it from the power supply. I filled the disc with ‘Unassigned Devices’ with zeros, did a PreClean and checked for errors. I also completely reconfigured the array using tools.
    I added the disc without partitions and once with XFS partition. None of this was successful.

     

    I have been using UnRAID for a long time and replaced all the discs once about 6 months ago without losing any data. I wouldn't consider myself inexperienced, but I'm absolutely stumped by this problem. 

     

    Enclosed is a screenshot of all the disks I use in the system. If I have understood this correctly, does unRAID still think that there is still a partition on it?
    image.thumb.png.62ff439725d7ad300b359d3c7b468ba9.png

    Link to comment
    JorgeB
    1 hour ago, Pardasus said:

    If I have understood this correctly, does unRAID still think that there is still a partition on it?

    AS of last diags yes, and you didn't answer this:

     

    2 hours ago, JorgeB said:

     

    5 hours ago, Pardasus said:

    And from sdb

    Is this disk1? That one must have a partition.

     

     

    Link to comment
    Pardasus

    Oh, sorry. I had sent a screenshot where you can see that disc 1 (sdb) and disc 2 have an xfs partition.

    The array is also fully functional with data on it. The system is currently only running without the parity disc.

    Edited by Pardasus
    Link to comment
    Pardasus 
    NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0         7:0    0  65.8M  1 loop /lib
loop1         7:1    0 373.6M  1 loop /usr
loop2         7:2    0    20G  0 loop /var/lib/docker/btrfs
                                      /var/lib/docker
loop3         7:3    0     1G  0 loop /etc/libvirt
sda           8:0    0   1.8T  0 disk
└─sda1        8:1    0   1.8T  0 part
sdb           8:16   0   1.8T  0 disk
└─sdb1        8:17   0   1.8T  0 part
sdc           8:32   0   1.8T  0 disk
sdd           8:48   1  29.2G  0 disk
└─sdd1        8:49   1  29.1G  0 part /boot
sde           8:64   1     0B  0 disk
md1p1         9:1    0   1.8T  0 md   /mnt/disk1
md2p1         9:2    0   1.8T  0 md   /mnt/disk2
nvme0n1     259:0    0 476.9G  0 disk
└─nvme0n1p1 259:1    0 476.9G  0 part
nvme1n1     259:2    0 476.9G  0 disk
└─nvme1n1p1 259:3    0 476.9G  0 part /mnt/cache

     

    And attached is the new diagnostic file.

    smarthomeserver-diagnostics-20240816-1910.zip

    Link to comment
    JorgeB

    I think I know what's going on, Unraid may think those disks are SSDs, possibly because they report TRIM support and/ore are connect by USB using the UASP driver, try this, with parity disk unassigned type:

      

    sgdisk -o -a 8 -n 1:32K:0 /dev/sdX

     

    Replace X with correct letter for parity, then assign the disk to parity and it should be accepted.

    Link to comment
    Pardasus

    Sorry, that didn't help either. 

     

    I still have a backup system running with 1 TB discs but otherwise the same equipment. I could also remove the parity disc there and try to add a new one. If the same thing happens there, it must be a bug. But then my backup system would also be without a parity disc 😞

     

    The hard drives are connected via USB. Only the cache is installed. 

    NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0         7:0    0  65.8M  1 loop /lib
loop1         7:1    0 373.6M  1 loop /usr
sda           8:0    0   1.8T  0 disk
└─sda1        8:1    0   1.8T  0 part
sdb           8:16   0   1.8T  0 disk
└─sdb1        8:17   0   1.8T  0 part
sdc           8:32   0   1.8T  0 disk
└─sdc1        8:33   0   1.8T  0 part
sdd           8:48   1  29.2G  0 disk
└─sdd1        8:49   1  29.1G  0 part /boot
sde           8:64   1     0B  0 disk
nvme0n1     259:0    0 476.9G  0 disk
└─nvme0n1p1 259:1    0 476.9G  0 part
nvme1n1     259:2    0 476.9G  0 disk
└─nvme1n1p1 259:3    0 476.9G  0 part

     

    Link to comment
    JorgeB
    12 hours ago, Pardasus said:

    Sorry, that didn't help either. 

    Please post the output of:

      

    fdisk -l /dev/sdc

     

    And new diags

    Link to comment
    JorgeB

    Unless you are not posting the entire output, there's no partition created, did you run the command I posted above?

    Link to comment
    Pardasus

    Sorry, I had executed the command and then tried a few things myself and deleted the partition again.

    Here is the output again after I executed the command: 

    Disk /dev/sdc: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: SPZX-22UA7T0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 1FD1DA89-03BA-4B5C-A7AD-5AF9E509A680

Device     Start        End    Sectors  Size Type
/dev/sdc1     64 3907029134 3907029071  1.8T Linux filesystem

     

    I then stopped the array again and tried to add the disc as a parity disc again. I then created a new diagnostic file.
     

    smarthomeserver-diagnostics-20240817-1203.zip

    Link to comment
    JorgeB

    Partition is fine now, problem is that the other ones a little larger, which doesn't make much sense:

     

    disk0: (sdc) WDC_WD20SPZX-22UA7T0_WD-WXQ2A53M2XKC size: 1953514532 

     

    disk1: (sdb) WDC_WD20SPZX-22UA7T0_WD-WXQ2A53M289X size: 1953514552 

     

    Post the full output from 

      

    fdisk -l /dev/sdb

     

    Link to comment
    Pardasus

    That's interesting. The parity disc (sdc) originally showed me an error. However, the extended smart test ran without errors and Unassigned was also able to fill the disc with zeros without errors.

    We partitioned the sdc as GPT, while the others were partitioned as ‘dos’. I did this under 6.x and it was done by unRAID itself when adding the discs.
     

    sda 

    Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: SPZX-22UA7T0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start        End    Sectors  Size Id Type
/dev/sda1          64 3907029167 3907029104  1.8T 83 Linux

     

    sdb 

    Disk /dev/sdb: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: SPZX-22UA7T0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start        End    Sectors  Size Id Type
/dev/sdb1          64 3907029167 3907029104  1.8T 83 Linux

     

    sdc 

    Disk /dev/sdc: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: SPZX-22UA7T0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 1FD1DA89-03BA-4B5C-A7AD-5AF9E509A680

Device     Start        End    Sectors  Size Type
/dev/sdc1     64 3907029134 3907029071  1.8T Linux filesystem

     

    Link to comment
    JorgeB
    35 minutes ago, Pardasus said:

    We partitioned the sdc as GPT, while the others were partitioned as ‘dos’. I did this under 6.x and it was done by unRAID itself when adding the discs.

    Yep, that was my bad, forgot that up to 2TB devices are partitioned MBR by Unraid, and that would explain the small capacity difference, first, and still trying to find out why this was happening, please post the full output of 

    lsblk -o name,rota

    Then use the UD plugin to delete the GPT partition from parity, then format the disk using UD, any filesystem will do, then post again

      

    fdisk -l /dev/sdc

     

    Partition will be created MBR, but to check the starting sector.

    Link to comment
    Pardasus

    lsblk -o name,rota 

    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 deleted the partition again and formatted it with UD.

    fdisk -l /dev/sdc 

    Disk /dev/sdc: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: SPZX-22UA7T0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start        End    Sectors  Size Id Type
/dev/sdc1        2048 3907029167 3907027120  1.8T 83 Linux

     

    Link to comment
    JorgeB

    Thanks, partition is now MBR as expected, but it's starting on the wrong sector, because the disk reports that it is an SSD:

     

    6 minutes ago, Pardasus said: 
    sdc            0
└─sdc1         0

    HDD should report 1 for rotational, can you connect the disk using SATA to see if it reports the same?

     

    P.S. what model USB enclosure are you using?

     

     

    Link to comment
    Pardasus

    Unfortunately, I don't have a PC with a SATA connection. The enclosure is a USB-C enclosure from URGREEN. But I found an interesting article about the problem.

     

    https://superuser.com/questions/352572/why-does-the-partition-start-on-sector-2048-instead-of-63

     

    I'm just wondering why unRAID 6.x partitioned my discs in DOS. Also on my backup system all disks are DOS partitioned / formatted. This would mean that if I also remove, delete and re-add the parity disc on the backup system, I would also get the same problem there.

    I'm a bit unsure now, is it a bug / a change from unRAID 7.0.0-beta.2 or do I have to empty my array disc, delete it and mount it again so that it also starts at 2048?
    From what I have read, it is no longer common to start at 63. But why did unRAID 6.x do this for me?

    Link to comment


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.

    ×

  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.

    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.

×
×
  • Create New...