steini84

Perfect thanks, this has been merged :)

No sanoid does a lot and you only need to write the config file Sent from my iPhone using Tapatalk

Just did

It works perfectly for me in Sanoid/syncoid and I might need to depricate the Znapzend plugin since I have not used it at all since my migration. This works exactly as you described and here you can see an example of my production profile: [template_production] frequently = 4 hourly = 24 daily = 30 monthly = 0 yearly = 0 autosnap = yes autoprune = yes and here you can see how the snapshots are currently root@Unraid:~# zfs list -t snapshot ssd/Docker/Freshrss NAME USED AVAIL REFER MOUNTPOINT ssd/Docker/Freshrss@autosnap_2023-12-16_23:59:15_daily 1.41M - 17.2M - ssd/Docker/Freshrss@autosnap_2023-12-17_23:59:03_daily 1.16M - 17.2M - ssd/Docker/Freshrss@autosnap_2023-12-18_23:59:05_daily 1.12M - 17.2M - ssd/Docker/Freshrss@autosnap_2023-12-19_23:59:18_daily 1.16M - 17.2M - ssd/Docker/Freshrss@autosnap_2023-12-20_23:59:11_daily 1.19M - 17.2M - ssd/Docker/Freshrss@autosnap_2023-12-21_23:59:17_daily 1.19M - 17.2M - ssd/Docker/Freshrss@autosnap_2023-12-22_23:59:09_daily 1.13M - 17.2M - ssd/Docker/Freshrss@autosnap_2023-12-23_23:59:03_daily 1.13M - 17.2M - ssd/Docker/Freshrss@autosnap_2023-12-24_23:59:16_daily 864K - 17.1M - ssd/Docker/Freshrss@autosnap_2023-12-25_23:59:08_daily 1.05M - 18.3M - ssd/Docker/Freshrss@autosnap_2023-12-26_23:59:12_daily 1.07M - 18.3M - ssd/Docker/Freshrss@autosnap_2023-12-27_23:59:13_daily 1.15M - 18.4M - ssd/Docker/Freshrss@autosnap_2023-12-28_23:59:06_daily 1.18M - 18.4M - ssd/Docker/Freshrss@autosnap_2023-12-29_23:59:20_daily 1.09M - 18.4M - ssd/Docker/Freshrss@autosnap_2023-12-30_23:59:18_daily 904K - 18.4M - ssd/Docker/Freshrss@autosnap_2023-12-31_23:59:03_daily 1.06M - 19.5M - ssd/Docker/Freshrss@autosnap_2024-01-01_23:59:03_daily 1.08M - 19.5M - ssd/Docker/Freshrss@autosnap_2024-01-02_23:59:07_daily 1.17M - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-03_23:59:10_daily 1.15M - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-04_23:59:09_daily 1.15M - 19.7M - ssd/Docker/Freshrss@autosnap_2024-01-05_23:59:06_daily 1.33M - 19.7M - ssd/Docker/Freshrss@autosnap_2024-01-06_23:59:23_daily 1.20M - 19.7M - ssd/Docker/Freshrss@autosnap_2024-01-07_23:59:20_daily 1.14M - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-08_23:59:15_daily 1.09M - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-09_23:59:12_daily 1.09M - 19.7M - ssd/Docker/Freshrss@autosnap_2024-01-10_23:59:21_daily 1.10M - 19.7M - ssd/Docker/Freshrss@autosnap_2024-01-11_23:59:21_daily 1.26M - 19.7M - ssd/Docker/Freshrss@autosnap_2024-01-12_23:59:02_daily 1.14M - 19.7M - ssd/Docker/Freshrss@autosnap_2024-01-13_23:59:25_daily 1.04M - 19.7M - ssd/Docker/Freshrss@autosnap_2024-01-14_13:00:09_hourly 944K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-14_14:00:17_hourly 824K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-14_15:00:11_hourly 840K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-14_16:00:23_hourly 856K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-14_17:00:32_hourly 856K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-14_18:00:04_hourly 752K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-14_19:00:16_hourly 768K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-14_20:00:10_hourly 792K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-14_21:00:36_hourly 800K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-14_22:00:08_hourly 760K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-14_23:00:45_hourly 648K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-14_23:59:21_daily 144K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-15_00:00:11_hourly 144K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-15_01:00:31_hourly 640K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-15_02:00:28_hourly 624K - 19.5M - ssd/Docker/Freshrss@autosnap_2024-01-15_03:00:01_hourly 616K - 19.5M - ssd/Docker/Freshrss@autosnap_2024-01-15_04:00:33_hourly 616K - 19.5M - ssd/Docker/Freshrss@autosnap_2024-01-15_05:00:10_hourly 568K - 19.5M - ssd/Docker/Freshrss@autosnap_2024-01-15_06:00:28_hourly 680K - 19.5M - ssd/Docker/Freshrss@autosnap_2024-01-15_07:00:39_hourly 768K - 19.5M - ssd/Docker/Freshrss@autosnap_2024-01-15_08:00:25_hourly 744K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-15_09:00:32_hourly 736K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-15_10:00:08_hourly 888K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-15_11:00:36_hourly 880K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-15_12:00:19_hourly 0B - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-15_12:00:19_frequently 0B - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-15_12:15:17_frequently 184K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-15_12:30:21_frequently 200K - 19.6M - ssd/Docker/Freshrss@autosnap_2024-01-15_12:45:16_frequently 0B - 19.6M - The system is really configurable and the documentation is really good: https://github.com/jimsalterjrs/sanoid

There seems to be a problem with the mbuffer package. You can install the older version, but all the Slackware packages i found for the latest version are the same. To install the older package you can use wget https://github.com/Steini1984/unRAID6-Sainoid/raw/167f5ad3dc1941ef7670efcd21fbb4e6e6ad8587/packages/mbuffer.20200505.x86_64.tgz installpkg mbuffer.20200505.x86_64.tgz Sent from my iPhone using Tapatalk

Forgot to update the reference to the new mbuffer package so the install failed on new installs (updates were fine). Fixed now Sent from my iPhone using Tapatalk

Updated to 2.2 and upgraded the Perl and mbuffer packages Sent from my iPhone using Tapatalk

Its probably easy to add the option to use the current GitHub build, but I’m tracking the releases. I will take a look at it Sent from my iPhone using Tapatalk

you are correct, dont know what i was doing earlier. thanks

It seemed to only create a folder, not a dataset.

Congratulations on integrating ZFS! *** MY BAD *** Creating a single disk share actually makes a datastore ***** I would like to create a ZFS-only shares on the array and have a separate datastore for each share to enable replication and snapshots. While going through the release notes, I came across the following information: "Top-level user shares in a ZFS pool are created as datasets instead of ordinary directories." However, I haven't found an official way to achieve this for a single ZFS drive within the array through the settings. Manually, it is easy to accomplish, but I wanted to think aloud and see if anyone has any insights into potential issues with my strategy in unRAID or if there are alternative approaches that align better with the "Out of the box - unRAID way". In my understanding, this approach should work, but I am unsure if I might unintentionally disrupt any underlying mechanisms in unRAID by manually creating the datasets. Here's what I have done so far: Converted disk 15 to ZFS. Manually created disk15/Nextcloud. Configured the included disk to only include disk 15. Migrated my existing data to disk 15. So far so good, but please let me know if you have any suggestions on a better strategy and/or if there are any potential concerns with my current setup. PS I guess Exclusive access is not relevant here since the folder is on the array, not a zfs pool.

This plugin is now depricated, but for all the right reasons: https://unraid.net/blog/6-12-0-rc1 Contrats to the team on this big milestone and I´m excited to play with native ZFS on my Unraid setup!

You are absolutly correct. He took my manual build process and automated it so well that I have not had to think about it at all any more! Really took this plugin to another level and now we just wait for the next Unraid release so we can depricate it

Just to put it out there. I have personally moved to sanoid/syncoid Sent from my iPhone using Tapatalk

You can get away with a oneliner in the go file / User Scripts: wget -P /usr/local/sbin/ "https://raw.githubusercontent.com/jimsalterjrs/ioztat/main/ioztat" && chmod +x /usr/local/sbin/ioztat But packing this up as a plugin should be a fun project

I want to keep the zfs package as vanilla as possible. It would be a great fit for a plugin Sent from my iPhone using Tapatalk

This is just an unfortunate coincidence, i would guess it´s cabling issues or a dying drive. Have you done a smart test?

You can also keep it under /mnt/cache but don't have it on the flash! Sent from my iPhone using Tapatalk

This not the first time that I've begin to lost control of my unraid server, but until now I didn't lost anything. All I can say, it's begun to appear with the version 2.0 of the plugin, but maybe that it's linked to something else? rohrer-enard.fr-diagnostics-20220220-1151.zip Are you keeping your docker.img on the zfs array? It can cause the lockup you are describing. Sent from my iPhone using Tapatalk

What I think would make most sense is to have the zfs plug-in as vanilla as possible and extra functionality to a companion plugin. Then the companion plug-in would continue to work when zfs becomes native [emoji41] Sent from my iPhone using Tapatalk

I use check_mk for monitoring and that works perfectly for everything from low space to high load and even failed pools. It takes some time to set up but is really good! A simple bash script can be rigged to check zpool status -x I can set one up when I'm in front of a computer Sent from my iPhone using Tapatalk

You are probably storing docker.img on the zfs pool and running the latest RC of unraid: You can also try to use folders instead of docker.img Sent from my iPhone using Tapatalk

You have truly taken this plugin to the next level and with the automatic builds it´s as good as it gets until we get native ZFS on Unraid!

You can do a pretty basic test using dd dd if=/dev/random of=/mnt/SSD/test.bin bs=1MB count=1024 If you want to test the read speed you change input and output *remember to change to a path within your zfs pool Sent from my iPhone using Tapatalk

Just run this command then reboot rm /boot/config/plugins/unRAID6-ZFS/packages/*