Zfs: default pool mountpoint name should conform to Filesystem Hierarchy Standard (/srv/poolname instead of /poolname)

Created on 28 Jun 2016  路  17Comments  路  Source: openzfs/zfs

when creating a pool without specifying the mountpoint, the mountpoint is constructed from root path plus the poolname, resulting in unexpected mountpoints such as /poolname that look at least a bit weird

I propose that zpool utility to conform to Filesystem Hierarchy Standard and use /srv instead of / for prefixing the mountpoint name if user did not specify a mountpoint.

from wikipedia

/srv
Site-specific data served by this system, such as data and scripts for web servers, data offered by FTP servers, and repositories for version control systems.

Most helpful comment

For consistency with the other implementations and the other reasons mentioned above let's leave the default behavior as is. That said, if someone wants to port the OS X patch so that functionality is available under Linux I'd certainly consider it for inclusion as long as the default behavior remains unchanged.

All 17 comments

We've done this on OS X with /Volumes, and made it configurable via the environment variable __ZFS_MAIN_MOUNTPOINT_DIR, if you want to look at porting such an option over to ZoL (though I doubt ZoL will want to make the default anything other than /).

on debian there is /etc/default/zfs, maybe an optional variable could go there

This would break compatibility with other operating systems though. An unset property is literally unset and its value constructed. FreeBSD and Solaris will still use the original default.

That's the whole point ;)

i don't quite understand what compatibility means in this context. is confusing other os in what way? the pool is going probably to be used only on linux. it is a burden to always remember to set a mount point when creating a pool on linux. why whould the admin bear this burden and not have an option to use the prefix of choice that is also backed by standards?

moreover, if the pool was to be imported on another os, I bet this would be a one time action, and anyway when you import a foreign pool you do it for two major reasons: migrate and rescue. if you migrate, you might need or not to modify the mountpoint, and if you rescue, you import with altroot.

in any case, this would be a a very small percentage from total number of linux pools that will die under linux and never be imported on other os.

i really don't understand how this which is a minoriity as a percentage of total number of linux pools has prevalence over linux naming standards.

ZFS rather sets its own standards by not using /etc/fstab, and we also follow a few Solaris conventions by defaulting to refuse to mount into non-empty directories by default.

Users are free to set mount points to whatever they want. These are just the defaults, and are consistent with Solaris for the sake of consistency and documentation coherency.

I think you've missed the point. This is about relocating all pools en masse, not about fiddling with mountpoints-per-dataset-per-pool.

And you think that's not going to cause a lot of trouble? My pool is in different locations when I boot between FreeBSD and Linux, etc.

@DeHackEd We've been doing it like this on OS X for a couple years now. So no.

@DeHackEd you can't aim to forever maintain consistency with oracle when the code has already split.

whatever os i'd be using, as an admin i feel it is a burden to have to provide the mountpoint on zpool create instead of having an os-recommended (and standard!) prefix.

@mailinglists35 By the way, there is a somewhat counter-intuitive way of "faking" this.

zfs set mountpoint=/srv train
zfs set canmount=off train
zfs create train/so
zfs create train/call
zfs set mountpoint=/srv boat
zfs set canmount=off boat
zfs create boat/me
zfs create boat/maybe

Now you'll have

/srv/so
/srv/call
/srv/me
/srv/maybe

as a side note, I wonder how did the original zfs got the default mountpoint[1] - the solaris os does not seem to have designated a directory for permanent mounts[2].

[1]

Default Mount Point for Storage Pools
When a pool is created, the default mount point for the top-level dataset is /pool-name

[2]
https://docs.oracle.com/cd/E26505_01/html/816-5175/filesystem-5.html

another issue i've just encountered is that if you later rename the pool, you also must change the mountpoint, since you've set it manually instead of having a default and after rename the mountpoint remains with "local" SOURCE

For consistency with the other implementations and the other reasons mentioned above let's leave the default behavior as is. That said, if someone wants to port the OS X patch so that functionality is available under Linux I'd certainly consider it for inclusion as long as the default behavior remains unchanged.

@lady-galadriel commenting here following your comment in https://github.com/zfsonlinux/zfs/issues/8213#issuecomment-449129865

I don't want to set mountpoint=legacy, because that property is inherited and I want descendent filesystems to be mounted below top level pool path.

What I want is to be able to have a configfile somewhere where I say "do this prefix for the mount path instead of using forward slash as the prefix for the mount path"

so instead of doing zpool create -m /srv/poolname pool /dev/sda, I want to do "zfsroot=/srv" in some configfile then zpool create pool /dev/sda would mount in /srv/pool

if you want it, port the code.

Even if I had the required C and zfs internals knowledge to write a PR, it would be useless as devs agreement on this was to

@behlendorf
leave the default behavior as is

the arguments being:

@DeHackEd
My pool is in different locations when I boot between FreeBSD and Linux, etc.

how many % of zfs on linux users dual boot their production pools between freebsd and linux often enough for them this to be an issue? even if it is in different locations, how does that affect the pool when using freebsd?

@DeHackEd
This would break compatibility with other operating systems

Please explain How exactly a ZoL code that does not make any on-disk-format changes would break compatibility with other operating systems?

@DeHackEd
we also follow a few Solaris conventions by defaulting to refuse to mount into non-empty directories by default.

How does this changes or contradicts in any way my feature request?

@DeHackEd
These are just the defaults, and are consistent with Solaris for the sake of consistency and documentation coherency

ZoL has grown a lot and adapted specifically to Linux since fork from a 9 year old last available Solaris open source code. Why adhere to a 9 year old documentation and not to 15 years old Linux standards[1]?
Today you cannot import a current Solaris pool and neither Solaris can import a current version ZoL pool. Where is the consistency?
ZoL has it's own wiki and manual pages, different than Solaris documentation and manual pages. Where is the coherency?

Besides this, I'll summarize other issues nobody answered or considered:

  1. If you rename a default-options created pool, the mountpoint dynamically changes to the new name. But if you rename a pool that has a custom mountpoint, you must also rename the mountpoint property. This is an administration burden.

  2. What is the rationale in original implementation for choosing the root directory for mountpoints? nobody bothered to answer. The Oracle documentation about Solaris 10 operating system filesystem hierarchy mentions nothing about zfs default mountpoints. https://docs.oracle.com/cd/E26505_01/html/816-5175/filesystem-5.html

  3. At least why ZoL doesn't act consistently on export for default and custom pools? I filed #4824 that was closed without reason.

[1]
https://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.pdf

Applications must never create or require special files or subdirectories in the root directory. Other locations in the FHS hierarchy provide more than enough flexibility for any package.

3.2. Requirements
The following directories, or symbolic links to directories, are required in /.
[...]
/srv Data for services provided by this system

Was this page helpful?
0 / 5 - 0 ratings

Related issues

schmurfy picture schmurfy  路  3Comments

FransUrbo picture FransUrbo  路  4Comments

marker5a picture marker5a  路  4Comments

pcd1193182 picture pcd1193182  路  4Comments

tronder88 picture tronder88  路  3Comments