I currently have 2x 18tb hdds, one is parity, the other is zfs disk1.

 

Disk 1 is currently emulated and the parity check is going to take around 2 months apparently due to the single zfs in array bug. All writes to disk are incredibly slow (30meg) where I was previously getting a fully saturated gigabit connection when using xfs. All of my dockers now run really slow when accessing the array too.

 

During my switch to ZFS I messed up and had a very painful 4 day (9tb) file copy operation across a gigabit connection to restore all of my data which is something I'm trying to avoid, the first time I did this operation to an xfs array it took roughly 24hrs.

 

My current theory is that with disk1 being emulated, I could do the following

1 stop the array

2 remove that disk from the array

3 add single disk as a pool and format it to xfs

4 copy all data back to the new xfs pool

5 reformat the array to xfs

6 copy everything back to the array

7 destroy the new pool and add that disk back to the array

 

Am I thinking along the right lines or am I likely to lose everything again this way?

 

Am I also correct in assuming that current write operations are being written to the parity disk and not disk1 since it hasn't yet finished a parity check?

 

Diagnostics attached

monster-diagnostics-20231121-0821.zip

51 minutes ago, allied-encumbrance5583 said:

Disk 1 is currently emulated and the parity check is going to take around 2 months apparently due to the single zfs in array bug.

There's no bug related to parity check being slow with zfs.

 

51 minutes ago, allied-encumbrance5583 said:

All writes to disk are incredibly slow (30meg) where I was previously getting a fully saturated gigabit connection when using xfs.

There's a bug about this.

 

52 minutes ago, allied-encumbrance5583 said:

My current theory is that with disk1 being emulated, I could do the following

1 stop the array

2 remove that disk from the array

3 add single disk as a pool and format it to xfs

4 copy all data back to the new xfs pool

5 reformat the array to xfs

6 copy everything back to the array

7 destroy the new pool and add that disk back to the array

That should work but if you only have parity and one data disk parity is a mirror, so you could do a new config and mount parity in a pool, format disk1 xfs and copy the data, once done re-add parity.

 

 

 

8 minutes ago, JorgeB said:

Quote

There's no bug related to parity check being slow with zfs.

I was referring the the bug relating to zfs writes, this seems to be making the reconstruction extremely slow

 

8 minutes ago, JorgeB said:

Quote

There's a bug about this.

That's what I was referencing in the first sentence, if it's something that's likely to be fixed in the upcoming weeks I guess I could wait but I can't live with this long term

 

8 minutes ago, JorgeB said:

Quote

That should work but if you only have parity and one data disk parity is a mirror, so you could do a new config and mount parity in a pool, format disk1 xfs and copy the data, once done re-add parity.

I'm not sure if I'm not quite understand what you wrote or if I didn't explain my setup well to begin with, here's a screenshot of my main disk setup...

1 hour ago, allied-encumbrance5583 said:

this seems to be making the reconstruction extremely slow

The bug doesn't affect rebuilds.

 

1 hour ago, allied-encumbrance5583 said:

I'm not sure if I'm not quite understand what you wrote

Do a new config, assign old parity as disk1, old disk1 as a pool (or disk2), start array, confirm disk1 mounts and format the pool/disk2 xfs, copy the data, once done do another new config to assign them to the desired slots.

 

Wouldn't I lose data if I remove the parity disk then add it as the main disk?

With just parity and disk1 Unraid array works like a mirror, it's a special case, assuming the array was created correctly, e.g., parity was added and synced, not done a new config with the "parity is already valid" box checked and then run a correcting correct.

In a strange turn of events, I went to perform this operation yesterday only to find that my disk transfer rate has increased from 30MB/s to 200MB/s. Is there some sort of settling in phase for zfs disks? I've not rebooted or physically touched the machine in the meantime, the only other thing I could put it down to is that there were a few docker image updates that happened yesterday (I've got them set to automatically update), I've moved a bit of data around on the main array too, by which I mean I've deleted a few files and added a few more.

 

I'm glad that the speed is back and that I can now leave it as is but I'm confused as to what's caused to speed up suddenly. Perhaps a new diagnostic file will help you to investigate the ongoing zfs issues.

monster-diagnostics-20231123-0739.zip

3 hours ago, allied-encumbrance5583 said:

Is there some sort of settling in phase for zfs disks?

Nope, and the filesystem used has no influence on rebuilding a disk.

 

The most common reasons would be a disk with slow sectors (could be any of the disks) or something was using the array.

Hi, I accidentally formatted a new disk to zfs in my xfs array a few weeks ago and just noticed it today. Is it possible to:

1. stop the array

2. unmount the zfs drive

3. start the array

4. format the zfs drive as xfs

5. stop the array

6. remount the zfs (now xfs)

7. and do a rebuild from parity?

STOP right now!!!!

Any formatting of a disk in the array will update parity and, as you may realize, a format operation will will cause the disk to appear empty! You will lose that 8.83TB of information stored on it. As an result of the parity being updated, a rebuilt of the disk will result in (essentially) a newly formatted disk.

You have to empty the disk first of all files. Then you can reformat the disk.

Look here for a way to change the format of a disk.

https://forums.unraid.net/topic/127551-linux-community-to-remove-reiserfs-from-the-kernel-in-2025/#findComment-1569190

EDIT: You must be on Unraid version 7.0 or later to use this mover functionality.

Edited August 26, 2025Aug 26 by Frank1940

Thanks @Frank1940 I appreciate it! I'll read the link. I'll see if I can get a spare HDD and transfer the files. It's weird though according to Glance the disk is barely used. (First number is used and second number is the total) Might be because I'm not familiar with zfs at this point I just use xfs for the flexibility.

Does anyone know why in the Main unraid dashboard it says 8.83TB used but on Glance it's only 256K used?

Edited August 26, 2025Aug 26 by Nanuk_

1 hour ago, Nanuk_ said:

Does anyone know why in the Main unraid dashboard it says 8.83TB used but on Glance it's only 256K used?

Click here and see what is on the disk:

That open up the Dynamix File Manager which will allow you to examine the disk's content and you should certainly be able to determine if there 8.8TB or only 256KB stored on it. There is a 'CALCULATE' button which will show info on each Share (or directory) stored on that disk.

Thanks again @Frank1940 ! I tried it. Looks like Glance is wrong. I'll just have to get another drive and transfer the files to it before reformatting it.

You probably have enough space on the other drives of your system to "move" the data onto them. There is an Unbalance plugin that which (I believe) will then move files back from those drives back to Disk 11. (I might be more tempted to just leave them there if there is enough free space on those first ten drives.)

34 minutes ago, Nanuk_ said:

Now you see why I would probably just leave them there . (At least most of them.... I might move a few off if I didn't have one-to-two hundred GB free on each drive.)