Support .zfs/snapshot access via NFS

[behlendorf]

While the .zfs/snapshot directory is supported in the latest source, it is not yet accessible via NFS. There are a few integrations issues with the Linux NFS kernel servers which still need to be worked out. This issue is to track that work.

[behlendorf]

The issue appears to be that zpl_encode_fh() is generating short rather than long fids for the snapshot entries. Short fids should be used for the normal zfs filesystem and the .zfs entires. However, long fids need to be used for the snapshot directories to ensure the object set is encoded. zfs_fid() is setup to do this but it assumes that the .zfsctl are part of a different filesystem from the normal filesystem. This is true on Solaris but not on Linux due to an implementation detail. We're going to need a different way to make the same check, we may also need to trigger automounting of the snapshot here.

[bubble1975]

Just checking back on this item - has any progress been made on this item? Maybe rc12 has some developments on it?

[behlendorf]

@bubble1975 I'd love to see this fixed, but so far nobody has found the time to work on it.

[imp]

This issue hurts me badly enough to make me look into it. @behlendorf Do you believe your comment above about Linux vs Solaris behavior still holds true ? It feels like latest changes to .zfs/snapshots hierarchy invalidated it. I've experimented with different approaches, but without any particular success meanwhile. I will summarize my observations and update this issue later.

[behlendorf]

@imp First off, thanks for starting to work on this. This is support I'd love to be using as well but I haven't had the time to dedicate to it. Doing it right is more complicated than it initially appears.

The above comments about the .zfs directory being part of the mounted dataset on Linux are true. But upon further reflection it's not clear to me that's part of the problem. Someone still needs to dig in to this and determine exactly what the problem is so I'm looking forward to your analysis. A few things to keep in mind when looking at this.

• Under Linux the snapshot won't be automounted until the .zfs/snapshot directory gets traversed which invokes the automounted. Under Solaris the automount is done as part of the lookup so a stat(2) would trigger it. Exactly how this applies to the NFS kernel server isn't totally clear to me.
• I believe when I last left this zfs_fid() was correctly generating long FIDs which encoded the snapshot id. See include/sys/zfs_vfsops.h:106 for a little discussion about how the NFS fids are encoded.
• There are the usual NFS issues about traversing file systems which need to be understood in this context.

[illenseer]

Are there any improvements made? This feature is very important for us, we need to export the snapshots via NFS. Are there any workarounds?

[behlendorf]

@illenseer Short of properly implementing this for Linux the only workaround I can think of is to manually mount the snapshot mount -t zfs dataset mountpoint and then explicitly export it via NFS.

[imp]

Just want to give a heads up for all the interested party - my college @andrey-ve and me spent a lot of time recently on this issue. The problem turned out to be quite entangled. We have a working solution which we are going to push for review shortly. (All the gory details are going to be in review)

[sriccio]

Just want to let you know that I've compiled the zfs-snap branch of @andrey-ve including those patches and now snapshots are accessible from NFS export mounted on another linux box. Good work :)

[micw]

This also might affect bind mounts (e.g. when trying to access a snapshot from within a linux container or a docker box): http://comments.gmane.org/gmane.linux.file-systems.zfs.user/20179

@behlendorf , what's the reason to have the milestone set to 0.8.0? It seems that there are working patches since more than a year. Solving this would allow much new use cases for zfs on linux.

[micw]

For bind mounts (e.g. in lxc containers) the issue can be workarounded by calling

mount --make-shared /path/to/mounted/volume

before creating the bind mount.

[behlendorf]

@micw Yes it's definitely not that far off, #2797 actually contains the latest version of the patches and they're something I hope to merge shortly after the next tag. It would be great if you could give the latest patches with a recent kernel and verify they work properly.

[segdy]

@micw Can you elaborate on the workaround with "--make-shared"? I was pretty excited when I saw it but unfortunately it does not work for me:

On the "root machine" (hardware node):

hwnode: # zfs create pool/test
hwnode: # zfs set snapdir=visible pool/test
hwnode: # mount --make-shared /pool/test
hwnode: # mount -n --bind /pool/test /var/lib/vz/root/200/mnt/test
hwnode: # zfs snapshot pool/test@first
hwnode: # zfs snapshot pool/test@second
hwnode: # touch /pool/test/testfile

Then, entering the OpenVZ container (conceptually should be the same as LXC):

container: # cd /mnt/test
container: # ls -a
.  ..  .zfs  testfile
container: # cd .zfs/snapshot
container: # ls -a
.  ..  first  second
container: # cd first
-bash: cd: first: Too many levels of symbolic links

... exactly the same result as without "--make-shared" :-(