root@Moker-Vet:~# lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS

loop0 7:0 0 651.3M 1 loop /usr

loop1 7:1 0 173.4M 1 loop /lib

loop2 7:2 0 100G 0 loop /var/lib/docker/btrfs

/var/lib/docker

sda 8:0 1 7.5G 0 disk

└─sda1 8:1 1 7.5G 0 part /boot

sdb 8:16 0 931.5G 0 disk

└─sdb1 8:17 0 931.5G 0 part

sdc 8:32 0 931.5G 0 disk

└─sdc1 8:33 0 931.5G 0 part

sdd 8:48 0 1.8T 0 disk

└─sdd1 8:49 0 1.8T 0 part

sde 8:64 0 3.6T 0 disk

└─sde1 8:65 0 3.6T 0 part

sdf 8:80 0 3.6T 0 disk

└─sdf1 8:81 0 3.6T 0 part

sdg 8:96 0 3.6T 0 disk

└─sdg1 8:97 0 3.6T 0 part

sdh 8:112 0 3.6T 0 disk

└─sdh1 8:113 0 3.6T 0 part

sdi 8:128 0 3.6T 0 disk

└─sdi1 8:129 0 3.6T 0 part

sdj 8:144 0 3.6T 0 disk

└─sdj1 8:145 0 3.6T 0 part

sdk 8:160 0 14.6T 0 disk

└─sdk1 8:161 0 14.6T 0 part

sdl 8:176 0 12.7T 0 disk

└─sdl1 8:177 0 12.7T 0 part

sdm 8:192 0 3.6T 0 disk

├─sdm1 8:193 0 2.4G 0 part

├─sdm2 8:194 0 2G 0 part

└─sdm5 8:197 0 3.6T 0 part

sdn 8:208 0 3.6T 0 disk

├─sdn1 8:209 0 1M 0 part

├─sdn2 8:210 0 15M 0 part

└─sdn3 8:211 0 3.6T 0 part

sdo 8:224 0 3.6T 0 disk

├─sdo1 8:225 0 1M 0 part

├─sdo2 8:226 0 15M 0 part

└─sdo3 8:227 0 3.6T 0 part

sdp 8:240 0 20T 0 disk

└─sdp1 8:241 0 20T 0 part

md1p1 9:1 0 3.6T 0 md /mnt/disk1

md2p1 9:2 0 3.6T 0 md /mnt/disk2

md3p1 9:3 0 3.6T 0 md /mnt/disk3

md4p1 9:4 0 3.6T 0 md /mnt/disk4

md5p1 9:5 0 3.6T 0 md /mnt/disk5

md6p1 9:6 0 3.6T 0 md /mnt/disk6

md7p1 9:7 0 3.6T 0 md /mnt/disk7

md8p1 9:8 0 3.6T 0 md /mnt/disk8

md9p1 9:9 0 3.6T 0 md /mnt/disk9

md10p1 9:10 0 1.8T 0 md /mnt/disk10

md11p1 9:11 0 3.6T 0 md /mnt/disk11

md12p1 9:12 0 3.6T 0 md /mnt/disk12

md13p1 9:13 0 3.6T 0 md /mnt/disk13

md14p1 9:14 0 3.6T 0 md /mnt/disk14

sdq 65:0 0 12.7T 0 disk

└─sdq1 65:1 0 12.7T 0 part

sdr 65:16 0 3.6T 0 disk

└─sdr1 65:17 0 3.6T 0 part

sds 65:32 0 3.6T 0 disk

├─sds1 65:33 0 2.4G 0 part

├─sds2 65:34 0 2G 0 part

└─sds5 65:37 0 3.6T 0 part

sdt 65:48 0 3.6T 0 disk

├─sdt1 65:49 0 1M 0 part

├─sdt2 65:50 0 15M 0 part

└─sdt3 65:51 0 3.6T 0 part

sdu 65:64 0 3.6T 0 disk

└─sdu1 65:65 0 3.6T 0 part

sdv 65:80 0 20T 0 disk

└─sdv1 65:81 0 20T 0 part /mnt/moker-vet

sdw 65:96 0 14.6T 0 disk

└─sdw1 65:97 0 14.6T 0 part

sdx 65:112 0 18.2T 0 disk

└─sdx1 65:113 0 18.2T 0 part

sdy 65:128 0 3.6T 0 disk

├─sdy1 65:129 0 2.4G 0 part

├─sdy2 65:130 0 2G 0 part

└─sdy3 65:131 0 3.6T 0 part

sdz 65:144 0 3.6T 0 disk

└─sdz1 65:145 0 3.6T 0 part

sdaa 65:160 0 3.6T 0 disk

├─sdaa1 65:161 0 1M 0 part

├─sdaa2 65:162 0 15M 0 part

└─sdaa3 65:163 0 3.6T 0 part

sdab 65:176 0 14.6T 0 disk

└─sdab1 65:177 0 14.6T 0 part

sdac 65:192 0 18.2T 0 disk

└─sdac1 65:193 0 18.2T 0 part

sdad 65:208 0 3.6T 0 disk

└─sdad1 65:209 0 3.6T 0 part

sdae 65:224 0 3.6T 0 disk

├─sdae1 65:225 0 2.4G 0 part

├─sdae2 65:226 0 2G 0 part

└─sdae3 65:227 0 3.6T 0 part

sdaf 65:240 0 3.6T 0 disk

├─sdaf1 65:241 0 1M 0 part

├─sdaf2 65:242 0 15M 0 part

└─sdaf3 65:243 0 3.6T 0 part

zram0 252:0 0 0B 0 disk

nvme1n1 259:0 0 931.5G 0 disk

└─nvme1n1p1 259:1 0 931.5G 0 part

nvme0n1 259:2 0 931.5G 0 disk

└─nvme0n1p1 259:3 0 931.5G 0 part

2 minutes ago, Kilrah said:

Then it problably already had a partition that should have been deleted before adding to array.

I assumed xfs / unraid was not able to handle hdd with more capacity then 10tb. but thats good news! i prefer to have 1 storage pool/array

Several of your disks have multiple partitions as shown by lsblk. Don't see anything that would fully account for missing half of a disk, but who knows what might have happened after you first noticed one of them was "shrunk"

7 minutes ago, Moker-Vet said:

i prefer to have 1 storage pool/array

That would be much simpler, understandable, and easier to maintain.

All HDDS repartitioned as necessary to only have a single partition each, and assigned to the Unraid array.

All SDDs repartitioned as necessary to only have a single partition each, and assigned to one or more pools depending on their size.

Seems like you really need to just start over with Unraid.

Do you have backups of all that data?

Unraid can erase the partitions on each disk and then create a full-size partition when it formats each disk.

It is to much data to fully backup for me as of now, i have to think on how to do this, roughly 100tb i would need to store somewhere.

and then i would have 3 pools i think, 1 cache, 1 array, and one pool for ssd only. is that correct?

my array only has 15tb in use. while my moker-vet pool has 86tb in use as a btrfs. is it an idea to move all data from array to moker-vet pool and then remove the array disks and add them to the moker-vet pool? then i would work with a btrfs pool instead of an xfs array.

You could create a new array with only those disks with a single partition, then use Unassigned Devices plugin to mount each multipartition disk and copy its data to the array. Then after an Unassigned Disks data was copied, it could be repartitioned and added to the array.

XFS array with 2 parity is what I would recommend since you have so many HDDs.

A cache pool for caching user share writes. Need to see what SSDs would work best for that.

Another pool for keeping data that needed to be stored permanentaly on fast storage, such as docker/VM related shares.

Each pool configured with multiple SSDs for redundancy.

Good point, that i could try!

I use my cache nvme disks to store my docker containers and databases.

I'm not sure how to deal with breaking your already existing multidisk pools though. Might need some more heads to think about that some more.

Instead of Unassigned Devices, maybe we could leave your multidisk pools alone until their data was copied to the array.

Going to take a while to analyze all this and see where each disk with multiple partitions is currently assigned and which disks with single partitions are already in the array.

Let's see if @JorgeB might be interested in this thread. He has a lot more experience with the various multidisk pool configurations.

Is the plan to keep the btrfs pool as his? Please note that btrfs raid5 is still considered experimental, recommend using zfs RAIDZ instead, though it's not as flexible.

If some of the disks that need repartitioning are already assigned to the array, is it possible to fix the partition without reformatting?

I was thinking just getting the array fixed as well as we could without breaking any pools, then copying all pool data to the array, then consider how pools should be configured.

Possibly raid5 pool has more data than will fit on array, haven't really analyzed it all yet. Maybe would have to break some pools just to get enough array disks for all the data.

shfs             50T   14T   36T  28% /mnt/user0

Looks like total array capacity is 50T. Maybe some of that is multipartioned disks though.

20 minutes ago, trurl said:

If some of the disks that need repartitioning are already assigned to the array, is it possible to fix the partition without reformatting?

Should not be possible in this case, unless the primary partition already starts at the beginning of the disk, it just doesn't go to the end. Good to see fdisk -l /dev/sdX for one of those disks.

Also note that for Unraid to repartition the disk, it must be erased first, i.e., after a new config you can do that, just formatting existing array disks keeps their partition layout.

These are all the multipartion from lsblk earlier

1 hour ago, Moker-Vet said:

sdm 8:192 0 3.6T 0 disk

├─sdm1 8:193 0 2.4G 0 part

├─sdm2 8:194 0 2G 0 part

└─sdm5 8:197 0 3.6T 0 part

sdn 8:208 0 3.6T 0 disk

├─sdn1 8:209 0 1M 0 part

├─sdn2 8:210 0 15M 0 part

└─sdn3 8:211 0 3.6T 0 part

sdo 8:224 0 3.6T 0 disk

├─sdo1 8:225 0 1M 0 part

├─sdo2 8:226 0 15M 0 part

└─sdo3 8:227 0 3.6T 0 part

sds 65:32 0 3.6T 0 disk

├─sds1 65:33 0 2.4G 0 part

├─sds2 65:34 0 2G 0 part

└─sds5 65:37 0 3.6T 0 part

sdt 65:48 0 3.6T 0 disk

├─sdt1 65:49 0 1M 0 part

├─sdt2 65:50 0 15M 0 part

└─sdt3 65:51 0 3.6T 0 part

sdy 65:128 0 3.6T 0 disk

├─sdy1 65:129 0 2.4G 0 part

├─sdy2 65:130 0 2G 0 part

└─sdy3 65:131 0 3.6T 0 part

sdaa 65:160 0 3.6T 0 disk

├─sdaa1 65:161 0 1M 0 part

├─sdaa2 65:162 0 15M 0 part

└─sdaa3 65:163 0 3.6T 0 part

sdae 65:224 0 3.6T 0 disk

├─sdae1 65:225 0 2.4G 0 part

├─sdae2 65:226 0 2G 0 part

└─sdae3 65:227 0 3.6T 0 part

sdaf 65:240 0 3.6T 0 disk

├─sdaf1 65:241 0 1M 0 part

├─sdaf2 65:242 0 15M 0 part

└─sdaf3 65:243 0 3.6T 0 part

@Moker-Vet

What do you get from command line with this?

fdisk -l /dev/sdm

These are all the disks currently assigned to the array

parity (sdad)
disk1 (sdaa)
disk2 (sdaf)
disk3 (sdj)
disk4 (sdo)
disk5 (sdn)
disk6 (sdz)
disk7 (sdu)
disk8 (sdt)
disk9 (sdr)
disk10 (sdd)
disk11 (sdae)
disk12 (sdm)
disk13 (sds)
disk14 (sdy)

12 minutes ago, trurl said:

@Moker-Vet

What do you get from command line with this?

fdisk -l /dev/sdm

These are all the array disks, those with multiple partitions noted:

parity (sdad)
disk1 (sdaa) multi
disk2 (sdaf) multi
disk3 (sdj)
disk4 (sdo) multi
disk5 (sdn) multi
disk6 (sdz)
disk7 (sdu)
disk8 (sdt) multi
disk9 (sdr)
disk10 (sdd)
disk11 (sdae) multi
disk12 (sdm) multi
disk13 (sds) multi
disk14 (sdy) multi

23 minutes ago, JorgeB said:

Should not be possible in this case, unless the primary partition already starts at the beginning of the disk, it just doesn't go to the end. Good to see fdisk -l /dev/sdX for one of those disks.

Also note that for Unraid to repartition the disk, it must be erased first, i.e., after a new config you can do that, just formatting existing array disks keeps their partition layout.

Hi Jorge,

In the second command you see the sdx command

Just now, Moker-Vet said:

you see the sdx command

Not asking for that specifically, X was just an example

Just now, trurl said:

Not asking for that specifically, X was just an example

Yes, the first command is the fdisk -l /dev/sdm