Support .zfs/snapshot access via NFS #1655
Conversation
|
Great job, andrey-ve ! |
|
@andrey-ve Excellent work! I'm thrilled someone had an opportunity to work on this. I'm not going to be able to review this immediately, but it would be very helpful if those who are interested in this support began testing this patch stack. |
|
Hi! @behlendorf Actually I've tested @andrey-ve patches on one of our zfs filers where we needed to access zfs snapshots from remotes linux clients via NFS and I can confirm it's fully working. We got no problem with it so far. Excellent work :) |
|
Good news! I still need to review these, but I did run the patches through automated testing. That uncovered some kernel compatibility issues which need to be resolved. It would be great to test build with a more more kernels and sort these out. For this initial failure the |
|
Tested @andrey-ve patches on Centos: Thanks for the great work |
|
@behlendorf : Hello Brian, |
|
@Milan-Benes Not a trivial fix, but this should be resolvable with a little work. Getting all the kernel portability code in place is one of the things blocking these changes from being merged. If someone could work on getting these changes building under 3.11 that would be a good start. |
|
Hi First off thanks for testing patchset on different platforms & just for support. Currently I'm working on this compatibility issue, I'll update in the beginning of next week regarding the status of this fix. |
|
@andrey-ve That would be great. If you can add the needed autoconf code to get things building under say 2.6.32 and 3.11 that would go a long way towards getting this ready to be merged. I'm happy to run it through our local build farm to check the other kernel versions for you. |
When it's need to decode snapshot file handly it hard to get snapshot sb. On the contrary on snapshot mount it's easy to get snapshot sb because mount path available in the context of snapshot mount. Signed-off-by: Andrey Vesnovaty <andrey.vesnovaty@gmail.com>
Prevents NFS client from detection of different fileids of snapshot root dentry before & after snapshot mount. Signed-off-by: Andrey Vesnovaty <andrey.vesnovaty@gmail.com>
Encoded file handle should provide enough info in order to detect right objsetid and right object in the objset defined by objsetid. If objsetid not provided (<fh langth> == SHORT_FID_LEN) it's assumed that objset of the exported fs should be used. The objsetid should be encoded for every snapshot dentry including root dentry; for snapshot root dentry zf_gen should be 0 Signed-off-by: Andrey Vesnovaty <andrey.vesnovaty@gmail.com>
In order to decode long file handly containing snapshot objsetid: 1 If snapshot defined by objsetid not mounted than it should be mounted; to trigger snapshot automount path_lookup(<full snapshot path>) issued (see 'save vfsmount to extract path to trigger automount' for details about getting <full snapshot path>). 2 Once snapshot mounted sb of the snapshot should be provided; (see 'save snapshot root dentry on snapshot mount' for details about getting sb of mounted snapshot). 3 If zf_gen of fh is 0 & sb got by objsetid is snapshot sb (actually long file handly used for snapshots only), then consider fh as snapshot root dentryi fh. Signed-off-by: Andrey Vesnovaty <andrey.vesnovaty@gmail.com>
When decoding snapshot file handly it may happen that the snapshot pointed by the handly currently not mounted, consequently snapshot automount should be triggered. In order to trigger automount path_lookup(<full path to snapshot>) need to be issued. The <full path to snapshot> should be something like: <zfs mount point>/<ctl dir name>/snapshot/<snapshot name> Unfortunately, <zfs mount point> part of the path isn't available in the context of file handly decoding. A simple way to have a <zfs mount point> in the context of file handly decoding is to save pointer to struct vfsmount in the context of super block creation. Limitations: 1 Unfortunately it's kinda hack; in general struct vfsmount shouldn't be accessed in the context of the filesystem itself. 2 Once HAVE_MOUNT_NODEV enabled current implementation wont work at all; It's looks like possible to port it to kernel version where HAVE_MOUNT_NODEV enabled but it will remain rather HACK than solution. 3 Theoretically the proper solution of the problem is to eliminate usage of automount and/or mount at all; just generate all snapshot related in core structures (inodes/dentries etc.) on access. Signed-off-by: Andrey Vesnovaty <andrey.vesnovaty@gmail.com> Conflicts: include/sys/zfs_vfsops.h module/zfs/zfs_vfsops.c Conflicts: include/sys/zfs_vfsops.h module/zfs/zfs_ctldir.c module/zfs/zfs_vfsops.c Conflicts: module/zfs/zfs_vfsops.c
Signed-off-by: Andrey Vesnovaty <andrey.vesnovaty@gmail.com>
… getattr Conflicts: module/zfs/zfs_ctldir.c
Signed-off-by: Andrey Vesnovaty <andrey.vesnovaty@gmail.com>
dmu_snapshot_list_next offp argument (ctx->pos) and dir_emit ctx->pos argument should have same value for reading same snapshot directory. dmu_snapshot_list_next modifies offp argument to point to next entry in the list. In order to provide dir_emmit with ctx->pos having same value as before call to dmu_snapshot_list_next temporary variable should be used and the value of ctx->pos should be updated right before the next call to dmu_snapshot_list_next. This fixes a regression that was introduced in commit 0f37d0c Linux 3.11 compat: fops->iterate(). Signed-off-by: Andrey Vesnovaty <andrey.vesnovaty@gmail.com>
|
Some testing on SLES11 SP3 (obs build instance): The Since Note that the So after applying #1655 to 0.6.2 you can try something like this: --- module/zfs/zfs_ctldir.c.orig 2014-04-01 12:48:37.756605773 +0100
+++ module/zfs/zfs_ctldir.c 2014-04-01 12:50:58.674195921 +0100
@@ -997,8 +997,8 @@
goto out_path_buff;
}
- error = path_lookup(path_buff, LOOKUP_FOLLOW | LOOKUP_DIRECTORY, &nd);
- if (!error)
+ error = kern_path_parent(path_buff, &nd);
+ if (!error)
path_put(&nd.path);
out_path_buff:It builds but be warned, may eat your gerbil. Edit: And a nice NULL pointer: So yeah, doesn't work just yet. |
|
@jzachwieja Please check your SLES11 SP3 kernel. |
|
I grepped The only thing in the region of that was: it's defined as: extern struct dentry *mount_nodev(struct file_system_type *fs_type,
int flags, void *data,
int (*fill_super)(struct super_block *, void *, int));There's also: #define MNT_NODEV 0x02in Just in case, I've put the src.rpm for the stock SLES11 SP3 kernel source at https://anorien.csc.warwick.ac.uk/kernel-source-3.0.76-0.11.1.x86_64.rpm - it will produce the /usr/src/linux used for building on SLES. Hope this helps anyway, don't hesitate to ask if you need more information. |
|
@andrey-ve Any update on this? I've replaced |
|
Adding some printk()'s (don't know a better way to debug a kernel module :), I found this: From syslog: This corresponds to the code: |
|
I DO have the HAVE_MOUNT_NODEV, so it seems that z_mnt isn't set (the only reference I could find where it is, is from your |
|
Since I have MOUNT_NODEV, my code calls But since No idea how to get to a |
|
I have already invested some time research: how to get The one of not HACK solutions is to do the same thing as user space does to get Unfortunately I don't have a time right now an in near future to address this issue. |
|
@jzachwieja - sorry for taking so long to respond. Take a look at 2 latest posts by @FransUrbo: as I can understand we can't get |
|
Unfortunately, I don't seem to have the necessary skills to do this, it's way to close to the core for my liking... So we have to wait for someone else to step up and take a crack at this. |
|
Thank you for the reply, I'll get the path construct into the kernel module and see how we get on with that. |
|
@jzachwieja: great, let me know if you have questions or need help. |
|
@andrey-ve could you please refresh this patch against the latest master. This will cause the buildbot to pick it up for automated testing and we can see what kind of kernel compatibility problems there still are. |
|
Will this patch also fix the EIO returned by mkdir()? |
|
I tried to adopt this patch to latest master. the compatibility issue seems easy to fix. I'm not so sure about the kernel panic one. |
|
Closing is favor of #2797. |
This patch is based on the previous work done by @andrey-ve and @yshui. It triggers the automount by using kern_path() to traverse to the known snapshout mount point. Once the snapshot is mounted NFS can access the contents of the snapshot. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#2797 Issue openzfs#1655 Issue openzfs#616
This patch is based on the previous work done by @andrey-ve and @yshui. It triggers the automount by using kern_path() to traverse to the known snapshout mount point. Once the snapshot is mounted NFS can access the contents of the snapshot. Allowing NFS clients to access to the .zfs/snapshot directory would normally mean that a root user on a client mounting an export with 'no_root_squash' would be able to use mkdir/rmdir/mv to manipulate snapshots on the server. To prevent configuration mistakes a zfs_admin_snapshot module option was added which disables the mkdir/rmdir/mv functionally. System administators desiring this functionally must explicitly enable it. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#2797 Issue openzfs#1655 Issue openzfs#616
This patch is based on the previous work done by @andrey-ve and @yshui. It triggers the automount by using kern_path() to traverse to the known snapshout mount point. Once the snapshot is mounted NFS can access the contents of the snapshot. Allowing NFS clients to access to the .zfs/snapshot directory would normally mean that a root user on a client mounting an export with 'no_root_squash' would be able to use mkdir/rmdir/mv to manipulate snapshots on the server. To prevent configuration mistakes a zfs_admin_snapshot module option was added which disables the mkdir/rmdir/mv functionally. System administators desiring this functionally must explicitly enable it. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes openzfs#2797 Closes openzfs#1655 Closes openzfs#616
This patch is based on the previous work done by @andrey-ve and @yshui. It triggers the automount by using kern_path() to traverse to the known snapshout mount point. Once the snapshot is mounted NFS can access the contents of the snapshot. Allowing NFS clients to access to the .zfs/snapshot directory would normally mean that a root user on a client mounting an export with 'no_root_squash' would be able to use mkdir/rmdir/mv to manipulate snapshots on the server. To prevent configuration mistakes a zfs_admin_snapshot module option was added which disables the mkdir/rmdir/mv functionally. System administators desiring this functionally must explicitly enable it. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes openzfs#2797 Closes openzfs#1655 Closes openzfs#616
This patch is based on the previous work done by @andrey-ve and @yshui. It triggers the automount by using kern_path() to traverse to the known snapshout mount point. Once the snapshot is mounted NFS can access the contents of the snapshot. Allowing NFS clients to access to the .zfs/snapshot directory would normally mean that a root user on a client mounting an export with 'no_root_squash' would be able to use mkdir/rmdir/mv to manipulate snapshots on the server. To prevent configuration mistakes a zfs_admin_snapshot module option was added which disables the mkdir/rmdir/mv functionally. System administators desiring this functionally must explicitly enable it. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes openzfs#2797 Closes openzfs#1655 Closes openzfs#616
This should fix #616 - support .zfs/snapshot access via NFS.
Current solution works until HAVE_MOUNT_NODEV disabled - more info can be found in : 73d84cf
During the development few issues not related directly to #616 have bin fixed as well: