Then let’s not say “correct”, but “most recent”, “intended by the developers of Manjaro/Arch/OpenZFS” or “rational”.
E.g. I’m not using datasets with the property mountpoint=legacy and the “official” OpenZFS Wiki also does not describe it like you said.
As far as I understand, my current configuration generates systemd mount units out of the fstab definition. But that’s exactly what I want to understand.
There are literally multiple ways to do it. All are rational. zfs in general isn’t a thing that only works a single way. It is intended to be flexible and used in different ways. Different people have different preferences.
That being said, the method described the arch wiki using the zfs-mount.service is definitely more common and more simple.
I just looked at the wiki you referenced. It looks like it is setting canmount=noauto on all datasets with mountpoints then mounting them manually by zfs using the zfsutils mount option in /etc/fstab. That is yet another valid way to do it.
For the dataset that isn’t working for you, did you set canmount=noauto and set the mountpoint properly
I don’t really think that is the “official method”. I think that the author’s preference. If a descriptive howto like that described all the options, it would be very long and confusing.
That is how fstab works on a system with systemd. It does that for everything in /etc/fstab with any filesystem.
I understand that, there is now “wrong” or “right”. But there has to be reasons to choose one or another solution. That is, what I’m trying to understand. E.g. my configuration, from the OpenZFS Wiki “Root on ZFS” for Arch, is using the fstab method, to control the order folders are mounted more precisely:
At boot, datasets on rpool are mounted with /etc/fstab , which can control the mounting process more precisely than zfs-mount.service .
So what are the pros and cons using other method?
As far as I understand it, it is using the canmount=noauto property only for the root dataset ‘rpool/manjaro/ROOT/default’. I’m not using a boot pool, that did not work out for me.
So for me the scheme is:
Every virtual dataset gets the canmount=off property set, because it just used for organisation and inheriting properties to child datasets.
The datasets for /usr, /var and /var/lib are set to ‘canmount=off’. This is mentioned in nearly any howto I found, even though I don’t know the actual reason.
All other datasets, which are actually mounted have the `canmount=on’ property set.
This is only useful/important if you need to control the order they are mounted more precisely.
One pro is that it is easier to manage. You just set the mountpoints and they instantly mount themselves. Especially as the number of datasets grows.
When you do that, they basically become containers for the datasets they hold. There is no reason to mount them or set their mountpoints. That being said, your layout, is very odd. From a peek at your fstab it looks like you are explicitly mounting nested datasets. What is the point of that? Most people would either allow them all to be implicitly mounted or don’t create those extra containers in the first place. Is that just how you keep them organized?
If you are mounting them in /etc/fstab, I don’t think you want canmount=on. That doesn’t seem to be what they recommend in the tutorial you followed either.
One important warning I would give you is that everyone does this kind of setup differently so if you are mixing and matching information from different tutorials, it is important that you have a detailed understanding of what you are doing or you will end up in a mess.
Ok, then why do they need to do this more precisely in the howto?
I just followed the wiki to get to a starting point and to learn something. I just don’t have a mirrored pool and I’m not using a separate boot pool, but anything else I have done, is as described the OpenZFS wiki.
As I said, I just followed the howto, which is also by the way, the most recent one. I still could have done something wrong, though.
I also understand this, but at some point you’ll have to try something to get a better understanding. I’m at this point now.
There isn’t enough information there to determine if it is needed or not. To be fair, I don’t usually use a boot pool so it could be needed there.
Alternatively, it may just be the author’s preference.
I do something similar but in my case it is because I multi-boot out of a single zpool and I have overlapping mountpoints. This is probably not a common use case though.
Maybe I am not reading that link closely enough but where it does it recommend creating a dataset called something like rpool_<randomUUID>/manjaro/DATA/default/var/lib/libvirt with that much nesting? I mean, you can, it will work. But what is the point?
The same thing could be achieved by the dataset rpool_<randomUUID>/manjaro/DATA/libvirt.
To be clear, I am not recommending you change it. I am just trying to understand why you would do it in the first place when you are explicitly mounting everything in /etc/fstab
For example, I have a dataset mounted at /home/dalto/.local/share/Steam. In your model, would you create a dataset called rpool_<randomUUID>/manjaro/DATA/default/home/dalto/.local/share/Steam?
That just seems like a bunch of pointless empty datasets to me.
But, ultimately, this is what I was referring to earlier. There are a bunch of different ways to do this stuff. As long as you understand why you do it that way and have a reason for doing so, great!
I don’t know the author, either and there is no description regarding this point, but I guess they wanted to stick to the folder structure and that’s it. I thought It would make sense and adopted it. It is not the only howto doing it in this way.
I know what you mean. I took some effort to think about my dataset structure and finally I adopted the structure from the OpenZFS Arch wiki.
Given your layout where everything is under your / dataset and you have canmount=on, I suspect it would work because the initramfs would probably mount them all.
I wonder why they create datasets for /var/games and /var/lib/AccountsService. I don’t know what goes in /var/games, mine is empty.
If the entries in 