So, my cache disk is ZFS since before 7.X.

Is the number of snapshots normal to be so huge?
(note that I rebooted the server an hour ago - because of some firmware updates)

 

Also since I remember some discussion about zfs "mode" (or something) that UNRAID prefers (?) in version 7.X (I am in 7.0.1 now)... Where can I check that and what do is that I should see to be ok?

 

This pool now DOES NOT have appdata/domains/system any more (I moved those away, but MAYBE they left behind zfs residue?), it only has temp data for mover to move to array (plus few data that need to remain there).

 

How do I clean up my snapshots/datasets, how do I know what is really obsolete, how can I automate this clean up? (if needed to automate - I am not sure how UNRAID manages this thing itself)

I remembered one dataset and it was taken in 2023? (I don't even remember if I had switched to zfs so far back)

Note that most datasets have mount point "legacy"...

Help?

Edited March 9, 20251 yr by NLS

If you have Docker in folder mode and with the "native" driver option yes it'll do that, and it's not recommended on zfs drives.

25 minutes ago, Kilrah said:

If you have Docker in folder mode and with the "native" driver option yes it'll do that, and it's not recommended on zfs drives.

Yeah my docker is in folder mode (and I prefer it that way except if someone points me at some strong arguments on why not).
Should I revert to other fs?  (what?)

Is the current situation a performance or wear issue?

I would recommend using an image, but you want a folder on zfs, make sure you change to the ovrlay2 driver, see the 7.0.0 release notes.

1 hour ago, JorgeB said:

I would recommend using an image, but you want a folder on zfs, make sure you change to the ovrlay2 driver, see the 7.0.0 release notes.

 

Thanks.

I found a second M.2 lying around under my desk  so I added a second pool, xfs formated, where mover (slowly?) moves my appdata, domains, system...

(yes kvm and docker are disabled, changed primary-secondary storage so that it moves them to new cache pool and then after mover, will switch them to only new pool)
I checked in my docker settings and is indeed in "native" mode. In the help it says that for xfs the "native" IS overlay2.

Supposing it will succeed moving (not completely sure yet), this will also indeed switch my docker directory to overlay2 or I still need to re-create it? (even if I leave in native that for xfs is overlay2)

 

Edited March 9, 20251 yr by NLS

The issue is only with zfs, with xfs you can use native.

9 minutes ago, JorgeB said:

The issue is only with zfs, with xfs you can use native.

 

Yes I understand that.
What I am asking is in this specific situation:

- docker directory was in a zfs volume and set to "native" (not overlay2)... native for this case is "zfs" (according to help)

- I move using mover this directory TO an xfs volume... native in this case means "overlay2" (according to help), but the folder contents were in the zfs volume before, that native means zfs...
...won't that be an issue?

 

I hope I am coming through, sometimes my English are far from perfect.
The question is about this specific case, where I move the docker folder to different fs.

 

(and to be honest I am not even sure if docker will work afterwards - if it doesn't then there is an issue I guess... also M.2 to M.2 so slow, mover still in appdata folder which is <10GB is not telling me that this will be without issues)

 

Moving docker folder is pointless, it'll be completely broken because since it's a folder and with native driver it currently relies on zfs features that won't be there on your xfs drive. Delete and recreate at the new path.

That's a reason why image is preferred, it's self-contained, doesn't care about what storage it's on and can get moved just fine. 

 

Also it's only the Docker filesystem that needs adjusting, appdata/domains/the rest of the system share are fine on zfs as is. 

Edited March 9, 20251 yr by Kilrah

3 minutes ago, Kilrah said:

Moving docker folder is pointless, it'll be completely broken because since it's a folder and with native driver it currently relies on zfs features that won't be there on your xfs drive. 

That's a reason why image is preferred, it's self-contained and can get moved just fine. 

 

Also it's only the Docker filesystem that needs adjusting, appdata/domains/the rest of the system share are fine on zfs as is. 

You posted this while I was posting my own reply and I guess you replied to that also without knowing.
So I guess after moving docker won't start and will need to delete and re-create the docker directory anyway.

Thanks.

 

I insist on keeping docker a directory, because I need more control of the contents (yes I know I must not touch them) and do not like the "black box limited in size" philosophy of docker image - and I am not in love with having one more fs layer (like VMs must have).

 

Edited March 9, 20251 yr by NLS

To close this, indeed after moving the docker directory, dockers cannot be seen and need to be reinstalled by "Previous Apps".

 

@JorgeB

That said... my zfs cache pool still shows more than a thousand snapshots (now that appdata/system/domains are not in that pool).

Is there a way to clean this up or I shouldn't care?

Probably need to manually destroy the system dataset on the cache.

2 hours ago, Kilrah said:

Probably need to manually destroy the system dataset on the cache.

 

Thanks. How?

 

(I am editing first post to clear out my current enquiry)

Edited March 9, 20251 yr by NLS

Post the output from

zfs list -t all <pool name>

 

Yes shows this:

NAME    USED  AVAIL  REFER  MOUNTPOINT
cache   163G   737G  61.5G  /mnt/cache

 

But...

...this scrolls down forever

Edited March 10, 20251 yr by NLS

Sorry, you cannot use the pool name, just:

zfs list -t all

 

But if they are in the root pool, no way to delete them other them one by one.

😟

that's not possible

(maybe a script? maybe just format it again in zfs or non zfs?)

 

see the output

https://pastebin.com/TZ9kdcEg

 

in between (and at the bottom) you will see the few existing mount points (in cache there are 11 folders and most are empty)...

all the others I don't know if they are needed in any way or how they were created and why

 

if I am going to be honest (and this is a general comment, not sure if it has anything to do with unraid's implementation), I don't really get in my case what benefit I have from this added complexity and what makes zfs so perfect and everybody loves it (all I see are new issues we never thought of having with a fs)

 

Edited March 10, 20251 yr by NLS

Yep, they are on the root pool, this means the docker folder wans't a dataset, for the easiest way to get rid of them, I would recommend backing up and reformatting the pool

Thanks, will do.

Again (and this goes to zfs, not to anybody here), this definitely sucks and I see the bother is way more than the benefit.

zfs might not be for my use case, so I will probably revert to xfs or something.

Will save me some RAM too.

 

...and done.