itimpi

There is a value you can set on a pool by clicking on the pool on the Main tab.

It is not a requirement that a disk be mounted for a parity check/sync to run - just that it is part of the array and not disabled.

Yes. It includes the sizes of all drives that have the top level folders.

I have no knowledge of likely dates but I would think we are talking about next year for it to become a stable release, possibly as a release candidate later this year. It is likely to depend on how many point releases it takes to get the current ZFS support completely stable as little issues are still popping up in the 6.12rc releases. It would be nice to be surprised with earlier availability

Note that parity is updated in real-time once you have it present and this can impact write speed even with Reconstruct Write (Turbo Write) enabled. Since you have SMR parity drive and SMR data drives either of these slowing down will impact speeds.

If you rename the folder on disk1 it will automatically become part of the Backup1 share.. This will happen even before you change the Included disks setting as that setting only applies to where New files go, not to reading existing files.

after you add a disk to a new slot in the array it will always shows as unmountable. At that point you need to use the format option (which is near the button to start the array). Just check first that the drive it is listing to be formatted is only the one you expect.

If you added it to the array then it should not be showing in Unassigned Devices Did you format it AFTER adding it to the array while it was showing as part of the array? If you format it is Unassigned Devices outside the array then this format is lost when you add it to the array.

ZFS is not very flexible when it comes to expanding a ZFS pool as it requires all drives in a vdev to be of the same type (if you use mixed sizes then all drives are assumed to be the smallest size). Also every vdev within a pool has to be of the same 'width' (i.e. no of drives) which makes adding single drives not an option. No idea if there are any timescales for lifting such limitations. If you want to use mixed drive sizes and add them on demand like you can with the current Unraid array then you should consider using BTRFS instead which DOES already support this. Ideally this would be done with the 6.13 release in mind when it is expected pools will be able to act as both primary and secondary storage.

It is currently a requirement that there is at least one drive in the array (a hangover from Unraid's origins), but if you do not intend to really use the main array then you can use something like a small flash drive to satisfy this requirement. It is expected that this requirement will be removed in the future (probably in the 6.13 release).

If you have just added the 18TB drive to a new drive slot in the array then Unraid will require you to format it from within Unraid before you can use it to create an empty file system of the type you have selected for array drives. Is this the current scenario or is the drive going unmountable after you have formatted it from within Unraid?

When you say that this is a new drive - do you mean that you have just added it to the Unraid array in a new slot? If so have you formatted in Unraid it after adding it to the array (which would be required in such a scenario)? If you have got past that and it is then going unmountable then please clarify this.

I believe that something like this is planned for the 6.13 release.

If a User Share is set up to use a ZFS format pool then Unraid will automatically create a dataset with the same name. Doing this manually or creating a folder manually can give unexpected behaviour.

Although it is possible to have a second copy of a file if you manually make copies to a different drive, Unraid will not be aware of this and will only present one copy to the user. If the drive holding that copy drops offline then Unraid will transparently revert to using the other copy even if it’s contents might be completely different with no warning this is taking place.

Yes - you can simply reorder the physical drives to match the GUI and reboot and the order in the GUI will stay unchanged.

Unraid does not care how or where drives are connected sp physically moving them around in the case will not affect the order in the Unraid GUI.

Can’t tell from the diagnostics what the problem might be. The temperature mode is always very hard to simulate properly when testing so the most likely to not behave as expected. Turning on the Testing mode logging in the plugin settings and letting it run for a short while (about 30 minutes) and post new diagnostics it might give me an idea of what is going if the parity check is paused when it should be resumed. Also make sure you are on the latest version of the plugin.

I agree these would be nice features to have but I think that the implementation problems are big enough it would be unlikely to get very high up the priority list any time soon.

Not really, The rebuild process is clever enough to handle writes being made to the disk being rebuilt and keeping everything correctly in sync.

It should be unnecessary as the rebuild by definition made the rebuilt drive agree with parity.

As far as I know you are the first person who has experienced this so there is probably something else going on. it might help if you attach your system’s diagnostics zip file to your next post in this thread.

Not quite sure what you are asking? You can set the default boot mode by clicking on the boot drive on the Main tab (with the array stopped) and go to the Syslinux Configuration section to set the default boot mode.

This topic is covered here in the online documentation. Note that a 'cache' pool is just a pool that is being used for caching a share - it is otherwise the same as any other pool.

Are you sure your PSU and the power cabling is up to handling this? Doing a parity check is normally when there is likely to be most power being used and even a temporary voltage dop can cause problems.