ephigenie

Ok i have thank you - with your help its figured out now. Now for everyone who faced the same issue - just to document it : With Perc 710 controllers - whereas the single disk was configured as a virtual disk you need to do the following, assuming you have to change more than 1 disk in a row - because i.e. like in my case with a poweredge T620 the drive cage is 2 x 4 drives connected via a 4i cable each so no way to take them separate. 1) make a screenshot of your (old) config & names then shutdown 2) change your cabling ( i.e. 4 disks at once ) 3) start unraid up again - it will complain too many disks are missing ... 4) make sure you see all your 4 disks but with (partition not readable / supported ) 5) go to tools -> new config 6) run sgdisk -o -a 8 -n 1:32K:0 /dev/sdX ( as in X is each disk so 4 times ) for those 4 disks that are not readable 7) run xfs_repair /dev/sdX1 afterwards try to start the array ( with the new config ) 9) it should be fine now, if not reboot once. 10) repeat step 1-9 with the 2nd batch of disks 11) good luck. This has been tested with PERC / DELL raid controllers

Ah well - you mean to say i shall remove unraid and install a windows server to get the GPT partition table right in order for unraid to recognize it? - that sounds funny No i mean the disks are already formatted with XFS and i can mount them manually inside unraid. Just the partition layout for some reasons doesn't seem to fit. That is the challenge. I have transferred files now to an unassigned standalone HDD from 2 disks ( 8TB & 16TB ) . After the transfer i did "sgdisk -o -a 8 -n 1:32K:0 /dev/sdX" on those disks and ran an xfs_repair /dev/sdX & reboot. Eventually i started as well the mkfs.xfs /dev/sdX just to get the error message ( partition already has a live XFS filesystem ). At some point after a reboot the partitions were recognized and i could add them into the config. I am about to finish the transfer back for the 16TB disk so 2 out of 8 are fixed now. After the 16tb disk i will try a different approach. Copying these amounts of data around is taking weeks.

Thanks for the tip - but also did not work out. I think Unraid sets somewhere a magic byte in the GPT header. Tried to find it with sleuthkit already - but could not find it so far - i can only say that all gpt headers created from unraid look slightly different then the ones created outside. in 2 Bytes. The other cylinder alignment etc pp are all the same. Update: Tried again - copied the files over from one of the drives to a new drive. Now i am trying to format that drive and let it be recognized in unraid. Still it does not recognize the disk.

Thanks for the tip - but also did not work out. I think Unraid sets somewhere a magic byte in the GPT header. Tried to find it with sleuthkit already - but could not find it so far - i can only say that all gpt headers created from unraid look slightly different then the ones created outside. in 2 Bytes. The other cylinder alignment etc pp are all the same.

Yeah ok - thats unfortunately not possible - since the cabling is via minisas 4i (Dell 620T - 8x3.5 case ) - so it's going to be 4 disks at a time. Exactly the scenario i have right now.... Is there no reasonable explanation as to what exactly unraid is looking for in the partition layout ? Could not be more than a few bites set at the right point?

If i mount i.e. my disk1 ( sdg1 ) to /mnt/disks1/disk1 manually : The mount message is the same ( again rightfully seeing V5 Xfs etc ) ... This is what i see for those disks... The parity drive (which works) with fdisk -l /dev/sdo root@bob:~# fdisk -l /dev/sdo Disk /dev/sdo: 14.55 TiB, 16000900661248 bytes, 31251759104 sectors Disk model: ST16000NM001G-2K 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: 0013AD91-3326-4479-A772-A0AFE8D4BBCA Device Start End Sectors Size Type /dev/sdo1 64 31251759070 31251759007 14.6T Linux filesystem and a similar size but not working : root@bob:~# fdisk -l /dev/sdg Disk /dev/sdg: 14.55 TiB, 16000900661248 bytes, 31251759104 sectors Disk model: TOSHIBA MG08ACA1 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: A1FEB878-5764-4167-91F8-AC9C8F88EC9C Device Start End Sectors Size Type /dev/sdg1 64 31250710494 31250710431 14.6T Linux filesystem cfdisk is showing the 512M at the end of the disk Now i am aware of course i can just reformat and then lose all my data and be done with that ... but that would be quiet the hassle. I also think i could in theory buy another 16TB drive, mount it into unassigned devices, format it - then mount one of my old drives - copy everything over than format the old drive and add it - but its a lengthy exercise ( with in total 8 drives ). Would be great if that can be shortened somehow. Update: I have ordered another Toshiba 16TB disk - but anyone can help please and explain the difference in the partition layout? bob-diagnostics-20240403-0018.zip

Needless to say in the above screenshot you can still see 4 more drives having the DELL naming ... those are coming as well over ( still on the old controller ) . For some reason i think technically it should be absolutely do-able to get unraid to mount and recognize the disks again. I will deep dive a bit more into what kind of partition layout unraid is formatting the other disks. In order to manipulate this disks to undergo the same layout.

soooo i got into the situation now ... that i have replaced the controller. But i cannot get them to mount into unraid as part of the Array. However i can mount separately individually without any issue... Any recommendations ? Below my old config with the perc710 controller (now i am using a 24i - 9306 or so LSI based controller ) Unfortunately now however - although the partitions look almost the same, it is saying "unknown partition layout" cannot mount. However on the command line i can mount them individually - so all my data is there. Now i would love to know what partition information / schema Unraid exactly is looking for - so i can change the disks partition layout. I mean start sectors are quite the same - just at the end seems there is a 512MB patch free that the other native unraid formatted disks dont have. All disks have UUID and actually show XFS as well here. Any ideas anyone ? I mean i have all my data still there ... ?

Hi, I have a fairly populated Unraid Server with approx 15drives so far. Those are distributed across 2 controllers. One of them is a legacy DELL Controller in NON-IT mode and the other one an updated IT mode SAS Controller. Now I have reached the point I need to add some additional disks via external DAE and want to add more controllers, but have not enough slots so I am forced to think about optimization of the current setup. My plan would be now to i.e. replace the existing controllers with this : SAS9305-24i LSI 9305-24i Logic Controller Card IT Mode 24-Port SAS 12Gb/s However - the naming is an issue of course. Now is there a "scan" feature available that would make Unraid recognize a disk ( its signature) although the name has changed ? Obviously that would only affect the disks connected as individual raid0 on the dell controller, the 7 disks on the IT mode controller would remain unchanged name wise and be recognized ( I assume ) . I am aware the whole idea and why its not recommended to use those raid controllers without the pass-through "IT" mode is for exactly this scenario (be independent of the controller) ... But such is life. Now I am searching for a solution. Anyone has a hint?

Same of me. Any update on this ? Tried setting the NVIDIA_DRIVER_CAPABILITIES & NVIDIA_VISIBLE_DEVICES flag for the container - but no chance

Did you try looking with IOtop which process is causing the amount of IO ? Can you trace it as well with docker stats across your containers ? Just to try to identify the verdict....

Well in parts i can agree - individual filesystems are an advantage. Unfortunately what i have seen while debugging shfs: is its highly unefficient. This and then along with the "mover" is causing a lot of issues. I get, that the overhead in IO is caused by being extra-cautios and double check everything. However since the approach of array configuration is not extendable during live operation as well as cache... The "only" configurable thing that is actually causing most of the confusion are the settings around the cache. And the involvement of the mover. To this part i would not understand why i.e. its not possible to make that a transition process, whereas upon all criterias are being fullfilled, a "progress - meter" can show the status of the transition. i.e. I change a share from "prefer" to "cache only" : nothing happens in terms of the mover. ( isn't that unexpected ? ) ? Given that the others : i.e. i change a share from "use cache" to "prefer" : the data will be copied from the array to the cache. But based on what pattern ? MRU ? LRU ? Specially the case of a share being converted to be "cache only" has some of the biggest problems in terms of workflow. Why not stop VM's & Docker and trigger a move by some i.e. rsync based tool on the shell ? Later on - even your share is still "cache only" SHFS triggered by the mover will still insist on over and overly seeking the share's FS on ALL disks. Something that definitely would need to be avoided in order to give the cache some sort of decent performance. Otherwise the disks that are supposed to be relieved are still needed for every run. And i validated this with strace ........ In terms of Cache & ZFS : Why would i not prefer having i.e. snapshots or a block wise cache ? I think there is almost no reason. in terms of different HDD sizes on ZFS : no issue at all. multiple arrays are possible as well.

You can try creating a raid1 / raid0 out of your 2 SSD's and putting XFS on top. Everyone please read: - https://en.wikipedia.org/wiki/ZFS ... - uptown triple-device parity per pool - of course multiple pools per host - builtin encryption - live extension - builtin deduplication - builtin hierarchical caching ( L1 Ram, L2 i.e. SSD ) blockwise and without possible data loss if the cache device dies with cache devices being able to be added and removed live and separate cache for fast write confirmation ( SLOG) - builtin "self-healing" - Snapshots... Only downside pools cannot be easily downsized. Really in short 98% of everything we dream about. I for myself like the comfort of the interface, VM and Docker handling, Ease of configuration of NFS, SMB etc And virtually none of that would fall apart. Filesystems are hugely complex beasts. And the amount of Forum entries here that are connected to performance issues of SHFS / mover are really a lot.

No. If you would look at their latest blog - and the video that was posted there - you would see that they are indeed considering ZFS. And i can tell you from my analysis - of the SHFS processes via strace and its behavior, that SHFS in itself has big issues performance wise. Guess why plugins like the directory cache and others exist. ZFS is the superior file system and it has decent Caching (block wise) build in amongst other features such as i.e. Snapshots, Raid etc. .. So imagine we would have the performance of XFS with the flexibility of BTRFS and snapshots and something like "dm-cache" build in. But all with the nice interface of Unraid and the easy handling of Docker Containers and VMs etc ... With ZFS on top, multiple pools wouldn't be an issue. Not to mention the amount of attention that any BUG in ZFS has in the worldwide community. Whereas if there is a serious bug in SHFS - its only in the hand of a few - and writing a filesystem is a very sophisticated task that needs a lot of time and resources. We would all profit from it - as well as LT. vid in question : https://unraid.net/blog/upcoming-home-gadget-geeks-unraid-show

Wow quit the impressive difference for you! Glad the change to XFS worked out for you. All the best! And yes i hope they will throw away this SHFS asap and replace it all with ZFS.