-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add temporary mount point properties #985
Comments
I believe this is because we haven't implemented temporary mount point properties. This work might happen for 0.6.3 because properly supporting them would allow us to more easily integrate with the full xfstests framework. From the zfs(8) man page:
|
case is handled. 2). In both files, the header and the C code, these options are now accepted as passed through by mount in util-linux-2.24 when it execs mount.zfs: acl noacl posixacl
Add the required kernel side infrastructure to parse arbitrary mount options. This enables us to support temporary mount options is largely the same way it's handled on other platforms. See the 'Temporary Mount Point Properties' section of zfs(8) for complete details. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes openzfs#985 Closes openzfs#3351
Add the required kernel side infrastructure to parse arbitrary mount options. This enables us to support temporary mount options in largely the same way it is handled on other platforms. See the 'Temporary Mount Point Properties' section of zfs(8) for complete details. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes openzfs#985 Closes openzfs#3351
Add the required kernel side infrastructure to parse arbitrary mount options. This enables us to support temporary mount options in largely the same way it is handled on other platforms. See the 'Temporary Mount Point Properties' section of zfs(8) for complete details. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes openzfs#985 Closes openzfs#3351
Add the required kernel side infrastructure to parse arbitrary mount options. This enables us to support temporary mount options in largely the same way it is handled on other platforms. See the 'Temporary Mount Point Properties' section of zfs(8) for complete details. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes openzfs#985 Closes openzfs#3351
Looking at the code, it appears temporary mountpoint support was penciled in to this code MNTOPT_MNTPOINT, but its implementation is incomplete. Is there any reason this functionality can't be fleshed out and made functional based on what's there? |
@TemptorSent could you be more specific? In what way is it currently incomplete? |
@behlendorf - As far as I can find, there is no means of setting the 'mountpoint' property on a temporary basis, as also mentioned in #4553. The only place I see MNTOPT_MNTPOINT ("mntpoint") used currently is a 'hint' for snapshots. I found no mention of ZPROP_SRC_TEMPORARY in combination with the mountpoint property, so as far as I can tell, only the ZFS_PROP_{ATIME,RELATIME,DEVICES,EXEC,READONLY,SUID,XATTR,NBMAND} are actually handled as temporary properties. Ideally, the mountpoint property should be able to be set temporarily at mount time AND be independent from the target mountpoint of the mount.zfs command. This would allow proper mountpoint inheritance for child datasets to work when mounting the parent in a temporary location, as well as properly supporting pivot_root from /sysroot to / without breaking subsequent automounting, such as Allowing temporary override of the mountpoint using |
@TemptorSent I see where you're going with this. The short answer is that there's no technical reason this couldn't be added, it simply hasn't been done. I agree it would definitely be nice to have, we just need a developer to implement it. |
@behlendorf - Excellent, thank you. I wanted to make sure there was no technical reason not to proceed with implementing it before wasting my time :) While I'm at it, should support for other temporary properties be implemented as well? |
Sounds good, thanks! While you're here I think adding support for |
Okay great! I'll start identifying the sections to modify then, starting with updating the docs and tests. |
It appears reopening this alongside #4553 would seem feasible for the case described in the last post. |
@almereyda
On Debian 11 (bullseye) with standard I can temporarily modify the mountpoint property, but that's messy and more likely to break something. |
Bumps [syn](https://github.com/dtolnay/syn) from 2.0.22 to 2.0.23. - [Release notes](https://github.com/dtolnay/syn/releases) - [Commits](dtolnay/syn@2.0.22...2.0.23) --- updated-dependencies: - dependency-name: syn dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
I have created a root pool, called "zfs-root" that my system is installed on and boots onto. zfs-root is using mountpoint=legacy and readonly=on. zfs-root pool is used directly as the root (/) filesystem.
When the system boots, zfs-root is mounted by default as readonly in the initramfs per the readonly=on property as expected and desired. When the system /sbin/init program runs on zfs-root, it remounts / to rw. This works fine. The zfs-root readonly property then has the value "off" (temporary).
Now, I created a zfs filesystem to use as maybe a virtual machine container, or user directory or whatever:
zfs-root/vm1 inherits mountpoint=legacy and readonly=on from zfs-root.
Then I make a directory as mountpoint:
Now, I mount it:
I just told mount to mount it read/write with "rw", but this what I get:
The kernel has actually mounted it ro, and I cannot write to it. mtab says rw, the option I gave to mount. Yet, it is not really rw. Information in mtab is wrong, but is what I asked for. This seems like a real bug: 1) I mounted for rw yet get ro. 2) kernel /proc/mount and userspace /etc/mtab do not agree.
I can remount:
This makes it rw, as originally requested from the first mount command.
Either this is a bug with how mountpoint=legacy and readonly=on are interacting, or it is a usage error on my part to set readonly=on while using mountpoint=legacy. I didn't see documentation about this conflict but maybe that is my error too. I am guessing that if one is using mountpoint=legacy, readonly=off (the default) should also be used. This could be documented for a dummy like me, or even take my possible suggestion: if mountpoint=legacy, then also readonly=legacy... a new value for readonly=property so they are consistent with each other. If mountpoint=legacy, readonly property gets locked to "legacy" also so you cannot change it really and must use "mount" command ro and rw options accordingly.
The text was updated successfully, but these errors were encountered: