Solved Mounting data-sets, canmount=off or mounpoint=none

M

mefizto

Greetings all,

I have been preparing my data-set hierarchy, and wonder whether I miss a conceptual difference between the two mounting options.

To exclude a data-set from a boot environment, there appear to be two options:
1. To create a parent-data set, mount it with a canmount=off and then create the child data-sets to be excluded under the parent; and
2. to create a parent-data set, mount it with a mountpoint=none and then create the child data-sets to be excluded under the parent.

Re 1, the alleged advantage is that the child data-sets inherits the the parent's property; the disadvantage is that zfs list results in list of data-sets, some of which, i.e., the parent are not mounted.

Re 2, the advantage is that zfs list results in list of only mounted data-sets; the disadvantage is that the child data-sets properties must be individually set.

However, it seems that both options ultimately yield the same result.

Am I missing something? Is there a "best practice"?

Kindest regards,

M
 
First off, I wouldn't be too concerned with what zfs list displays by default. There is a plethora of options you can pass to the command to modify its output. With a bit of simple shell magic, you can make yourself a custom-tailored command for listing datasets however you like.

Now, back to what this thread is about. You've already mentioned the key distinguishing characteristic between canmount and mountpoint, but seem to have glossed over its significance: canmount doesn't get inherited, mountpoint does.

Datasets that have canmount=off are typically used as vehicles for managing properties. For example, consider the case of a dataset whose canmount=off and mountpoint=/somepath:

Code: 
# zfs list -r -o name,canmount,mountpoint coolstuff/mydata
NAME                         CANMOUNT  MOUNTPOINT
coolstuff/mydata                  off  /somepath
coolstuff/mydata/build             on  /somepath/build
coolstuff/mydata/code              on  /somepath/code
coolstuff/mydata/music             on  /somepath/music

Any child datasets will automatically have their mountpoint property set accordingly without you having to explicitly set it because mountpoints are inherited in ZFS. But because canmount is not inherited, you won't have to worry about setting canmount=on for any child datasets you create--that will already be the default.

It might be helpful if you clarify what exactly you mean when you say you want datasets to be excluded from a boot environment. Depending on what it is you're trying to accomplish, there might be several ways to go about it. Typically, datasets that are not children of a particular boot environment dataset would not be considered part of said boot environment.

One way to go about laying things out might look like this:

Code: 
# zfs list -r -o name,canmount,mountpoint syspool/ROOT
NAME                         CANMOUNT  MOUNTPOINT
syspool/ROOT                      off  none
syspool/ROOT/bootenv1          noauto  /
syspool/ROOT/bootenv2          noauto  /
syspool/ROOT/bootenv3          noauto  /

While another might be:

Code: 
# zfs list -r -o name,canmount,mountpoint syspool/ROOT
NAME                         CANMOUNT  MOUNTPOINT
syspool/ROOT                      off  none
syspool/ROOT/bootenv1              on  /
syspool/ROOT/bootenv2             off  /
syspool/ROOT/bootenv3             off  /

The benefit of the first approach is that you don't need to toggle the canmount property between boots, and can boot into any boot environment regardless of what you used last or what the bootfs property on the zpool is. This is my preferred approach. However, the second approach might be better when you have several child datasets that need to be mounted alongside your boot environment's root dataset. (I say "might" because it's been a while since I last checked how various combinations of canmount/mountpoint are handled by FreeBSD when mounting multiple datasets per boot environment. Hopefully, somebody authoritative drops by to give us some clarification.)

In any case, share what plans you have for your layout and I'm sure you'll find plenty of folks eager to give you advice.
 
Hi redpill,

thank you for the reply.
redpill said:
Any child datasets will automatically have their mountpoint property set accordingly without you having to explicitly set it because mountpoints are inherited in ZFS. But because canmount is not inherited, you won't have to worry about setting canmount=on for any child datasets you create--that will already be the default.
Click to expand...
In my understanding, the last sentence assumes that either the canmount=on is set at the pool level or the on is a default value; the latter although true in Solaris' implementation, zfs(8) does not define a default value for the canmount property.

I have not even thought about the use of canmount in the second example that you have given, which was one reason for my question.

Returning now to my immediate concern, consider that one does not want certain data-sets to be included in the boot environment, e.g., /var/crash, /var/log, /var/mail, /var/tmp. Referring back to my original post, one way to achieve this is as follows:
Code: 
tank                       none
tank/ROOT                  none
tank/ROOT/master           /
. . .
tank/variable              /var
tank/variable/crash        /var/crash
tank/variable/log          /var/log
tank/variable/mail         /var/mail
tank/variable/tmp          /var/tmp
and setting canmount=off on the /var.

The second way to achieve this is as follows:
Code: 
tank                       none
tank/ROOT                  none
tank/ROOT/master           /
. . .
tank/variable              none
tank/variable/crash        /var/crash
tank/variable/log          /var/log
tank/variable/mail         /var/mail
tank/variable/tmp          /var/tmp
What I am concerned about is that given my lack of detailed understanding, I may run into problem later on. Hence my question whether one or the other is preferable or, what are the consequences of one or the other option.

Kindest regards,

M
 
mefizto said:
In my understanding, the last sentence assumes that either the canmount=on is set at the pool level or the on is a default value; the latter although true in Solaris' implementation, zfs(8) does not define a default value for the canmount property.
Click to expand...

You're right. It doesn't. Somebody should add some clarification to the man page. But when you create a new dataset, the canmount property is set to on by default.

mefizto said:
Returning now to my immediate concern ...
Click to expand...

If you only ever plan to have a few datasets beneath tank/variable that you're going to configure once and leave alone then--assuming that in both cases canmount=off on tank/variable--there's little difference between approach number one and two; aside from the fact that you will only have to set the mountpoint property once (on the parent dataset) with the first approach.

However, that latter point hints at the benefit. Here we are only talking about mountpoints, but child datasets inherit other properties too. It's convenient to be able to edit a property on only one dataset and have all the children inherit it. This is especially true when there are a lot of children or, more importantly, when you are regularly destroying and creating sub-datasets or manipulating their properties.

In your case, there's no harm in experimenting with either approach. There aren't really any non-obvious consequences to changing the canmount and mountpoint properties.
 
You must log in or register to reply here.
Back
Top