Kjeld

Thanks for the help all. I ended u useing "New Config" with my old drives. The new SSD's crashed during calculating from parity to a new drive. So I had two broken SSD's. I popped in the original HDD's in teh correct order and did the new config. Its doin parity calc a swe speak. So I am never going to use SSD's and don't recomend anyone doing it. I kept my head clear and did not panic and kept te original drives, so crisis averted.

I am going to make a drive copy. If the data is the same on the drive will the settings for Untaid like Docker images and VMs also stay working after this? Also thanks for helping.

Dear support, I have a problem with a replacing of a HDD to a SSD. My Unraid system tels me that the drives are not the same size. But when I check on the system via terminal. root@void-unraid:~# blockdev --getsize64 /dev/sdf 4000787030016 They are the same. ChatGPT tels me to use "New Config" to populate the array for "New". But the text in "New Config" is so vage that I don't dare using it. See the screenshot for my disk config. Can someone explain the "New Config" stuff?

It seems that most data on Disk1 was /video root@void-unraid:~# ls -rtlha /mnt/user/ total 16K drwxrwxrwx 1 nobody users 6 Jan 12 2022 docker-store/ drwxrwxrwx 1 nobody users 20 Jan 13 2022 appdata/ drwxrwxrwx 1 nobody users 90 Jan 17 2022 isos/ drwxrwxrwx 1 nobody users 36 Jan 26 2022 vms/ drwxrwxrwx 1 nobody users 6 Feb 9 2022 domains/ drwxrwxrwx 1 nobody users 104 Sep 26 20:51 ./ drwxrwxrwx 1 nobody users 35 Sep 26 20:51 system/ drwxr-xr-x 12 root root 240 Sep 27 13:59 ../ drwxrwxrwx 1 nobody users 8.0K Sep 27 14:14 video/ drwxrwxrwx 1 nobody users 6 Sep 28 08:45 time-machine/ No lost+found extra directory there. All looks good, thanks again.

That worked! Wow, is this normal? My stress level was up there. Thanks for the quick response/support. I did lose some faith in the software. But thanks again JorgeB!

Phase 1 - find and verify superblock... - block cache size set to 612184 entries Phase 2 - using internal log - zero log... zero_log: head block 0 tail block 0 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 3 - agno = 2 - agno = 4 - agno = 5 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... XFS_REPAIR Summary Tue Sep 27 13:10:24 2022 Phase Start End Duration Phase 1: 09/27 13:07:52 09/27 13:07:55 3 seconds Phase 2: 09/27 13:07:55 09/27 13:07:56 1 second Phase 3: 09/27 13:07:56 09/27 13:09:44 1 minute, 48 seconds Phase 4: 09/27 13:09:44 09/27 13:09:45 1 second Phase 5: 09/27 13:09:45 09/27 13:10:04 19 seconds Phase 6: 09/27 13:10:04 09/27 13:10:23 19 seconds Phase 7: 09/27 13:10:23 09/27 13:10:23 Total run time: 2 minutes, 31 seconds done Does not seem to change anything.

Here is the full zip [removed]

I don't understand why the second image is there. The rebuild after placing in a new drive and with the blue icon I end up with the above images. Disk1 was broken and replaced. It also has been written to a lot in the past 18 hours. Please advise.