Hey guys,

 

New to Unraid, in the process of migrating and consolidating.

Added my second parity drive the other day and the latest data drive - Disk 9, was showing 'unmountable: wrong or no file system. After the parity drive added successfully, I swapped Disk 9 out with a spare drive I had laying around to test if my breakout cables were bad. New Disk 9 is showing the same unmountable error. 

 

There was no data on disk 9 so I wasn't worried about losing anything. Started the array after swapping the disks (unassign, shutdown, assign) and Unraid is rebuilding from parity which will take 30 odd hours.

 

Strangely, Disk 1 has dropped from 50% usage with 11tb used down to 7.5tb used...

 

Disk 1: 7.5tb used

Disk 2-6 11tb used

Disk 7: 8.24tb used

Disk 8: 153GB used

Disk 9: unmountable

 

If it explains it, Parity 1 is 22tb, Parity 2 is 24tb. Waiting on my next 24tb disk to arrive to replace P1.

 

Any idea what's going on?

Replacing/rebuilding disks won't fix unmountable filesystems, typically you need to check filesystem.

 

6 hours ago, dozerplex said:

Strangely, Disk 1 has dropped from 50% usage with 11tb used down to 7.5tb used...

Unraid doesn't move/delete array data disks on its own, so something/someone else did that.

 

 

Thanks JorgeB, I would've assumed that a brand new disk with a new fs would have fixed the issue.

 

Why would the same issue appear across 2 new disks?
 

Open to any and all suggestions over what (or whom) could have moved data specifically from one disk in the array, and to where?

 

I've got no movers configured for cache/array or array/cache, one RecycleBin plugin and I'm the only one with administrative access. As far as I can tell at a glance no data is missing from the array but there's potentially 100tb to sift through.

 

Edit: It appears to be rebuilding data, but no data would have been lost as Disk 9 (replaced) had no data on it. Up to 2tb being rebuilt so far but not seeing an increase in storage utilised?

 

Still in the testing phases of unraid, this being part of the tests I had planned before putting it into 'production' so any insight would be appreciated. Should've done this with 2-3 drives but everything looked pretty solid until now. Still better to fiddle with it now than in 6 months when its my primary server.

Edited March 26, 20251 yr by dozerplex

18 minutes ago, dozerplex said:

I would've assumed that a brand new disk with a new fs would have fixed the issue.

But that's the issue, when you rebuild/replace a disk you are using the previous filesystem, not a new one.

 

Please post the complete diagnostics.

12 minutes ago, JorgeB said:

But that's the issue, when you rebuild/replace a disk you are using the previous filesystem, not a new one.

 

Please post the complete diagnostics.

 

Assuming that's unraid specific? I would have assumed it would have formatted the drive in XFS before trying to mount it then correct with parity data like regular RAID?

 

Sorry to be a pest, but which log files would you need? Would prefer not to post identifying information, are you able to give me a slimmed down list so I can obfuscate anything identifiable? If not, I'll go through and adjust a few serial numbers and whatnot.

 

Appreciate the assistance! 

 

 

 

1 hour ago, dozerplex said:

I would have assumed it would have formatted the drive in XFS before trying to mount it then correct with parity data like regular RAID?

That's not how parity works, if you replace/rebuild a disk, its contents will be the result of the other disk + parity, doesn't matter if/how the new disk was formatted before using it:

https://docs.unraid.net/legacy/FAQ/Parity/

 

1 hour ago, dozerplex said:

Sorry to be a pest, but which log files would you need?

The diags are anonymized by default, device serial number do show, and don't see how that is a problem, but it's up to you.

 

unraid-01-diagnostics-20250326-2020.zip

9 minutes ago, JorgeB said:

That's not how parity works, if you replace/rebuild a disk, its contents will be the result of the other disk + parity, doesn't matter if/how the new disk was formatted before using it:

https://docs.unraid.net/legacy/FAQ/Parity/

 

The diags are anonymized by default, device serial number do show, and don't see how that is a problem, but it's up to you.

 

 

Replaced one today in an old R710, it definitely asked to erase before re-adding to the RAID6 array, my mistake for incorrectly assuming how parity function's.

Thanks for the continued advice, learning as I go with all this. Please find diagnostics attached.

Are you sure disk9 was ever formatted? Post the output from:

 

blkid

 

Maybe it wasn't...

 

/dev/sda1: LABEL_FATBOOT="UNRAID" LABEL="UNRAID" UUID="1B22-2846" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="ff68e290-01"
/dev/md1p1: UUID="08da9a14-c0ba-425e-826b-8f543113d7ec" BLOCK_SIZE="512" TYPE="xfs"
/dev/md2p1: UUID="ad40ee31-afc3-42f4-9f91-8abdee2f3ba0" BLOCK_SIZE="512" TYPE="xfs"
/dev/md3p1: UUID="be895efa-a0e9-482c-b4f7-314e2b95d913" BLOCK_SIZE="512" TYPE="xfs"
/dev/md4p1: UUID="54eb373e-542e-43f4-b2b0-dcc09ce3bbe8" BLOCK_SIZE="512" TYPE="xfs"
/dev/md5p1: UUID="d5f2d458-1dc5-4555-b9a6-1cfe38768740" BLOCK_SIZE="512" TYPE="xfs"
/dev/md6p1: UUID="7ad458ab-76a6-4899-85b6-797aa5368b8a" BLOCK_SIZE="512" TYPE="xfs"
/dev/md7p1: UUID="f9ddb378-d196-420d-9abc-525002ac53f8" BLOCK_SIZE="512" TYPE="xfs"
/dev/md8p1: UUID="b27299f6-82f2-4f85-b004-d3d8429b2d22" BLOCK_SIZE="512" TYPE="xfs"
/dev/loop1: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/nvme0n1p1: UUID="6b7c90a9-8fd1-4780-a8b1-b8cb4fabe8eb" UUID_SUB="032ec031-b254-4cb9-ac26-53286d7be59d" BLOCK_SIZE="4096" TYPE="btrfs"
/dev/nvme2n1p1: UUID="6b7c90a9-8fd1-4780-a8b1-b8cb4fabe8eb" UUID_SUB="958e6a7f-96fd-4f96-9d40-ac3de7ea224e" BLOCK_SIZE="4096" TYPE="btrfs"
/dev/loop0: BLOCK_SIZE="131072" TYPE="squashfs"
/dev/loop2: UUID="0c6f54cb-1117-4c77-9f0c-57d73929a089" UUID_SUB="76da6356-0436-447c-a7c2-6a5dfe18d616" BLOCK_SIZE="4096" TYPE="btrfs"
/dev/loop3: UUID="e7bfabf3-b6ae-49f5-ad73-feefa5930133" UUID_SUB="135ceea0-83ed-4b7e-b95e-c463a02902f5" BLOCK_SIZE="4096" TYPE="btrfs"

 

I guess I'll just format it when the parity sync completes?

 

Nonetheless, the primary concern is where the hell my 3tb odd of data on disk 1 vanished to.. any insights?

24 minutes ago, dozerplex said:

Maybe it wasn't...

Most likely.

 

24 minutes ago, dozerplex said:

the primary concern is where the hell my 3tb odd of data on disk 1 vanished to.. any insights?

That I can't help with:

 

4 hours ago, JorgeB said:

Unraid doesn't move/delete array data disks on its own, so something/someone else did that.

 

I'd know if I removed 3-4tb worth of data.

 

Is there logs I can access for that drive that may give us a clue?

Individual reads/writes are not logged. If mover logging is enabled the moves would be logged.

 

Easy to drag files and accidentally drop them in the wrong place. If you dragged files from one user share and accidentally dropped them in another user share, they could end up on a different disk.

 

Other processes could be involved, such as specific docker containers. Some applications have the ability to add/modify/delete/move your data. That is often their purpose.

Well that's the thing..

 

Definitely haven't dragged/dropped to a different share, only have the one mapped. Everything copied across is 'precious' media files which I'm quite careful with. No docker containers installed and no programs that would move/delete data are running.

 

Trying to rack my brain to think if I've done any major deletes over the last few months to re-copy things for some reason, one occurrence springs to mind but the situation could be completely fabricated as you have incepted the idea that I have deleted something. Obviously it didn't just do it itself...

Guess this is going to just eat me alive.

 

Thanks for the help guys, will keep you posted regarding the unmountable drive.

 

Parity check finished.

 

Formatted disk 9 and its in the array.

 

Seems to be using 400GB of data post-format compared to the usual 153GB and has a 53 billion writes to it.

 

Everything seems happy so far, was a good test if nothing else.

Thanks for the help guys!

2 hours ago, dozerplex said:

Seems to be using 400GB of data post-format compared to the usual 153GB

The file system overheads have gone up when using XFS in recent Unraid releases due to additional functionality at the XFS level.  
 

I believe it is possible to reclaim some of this space by reformatting manually using different settings to the ones Unraid now uses, but I would be wary of doing this unless you are confident working at the Linux level.