zfs discuss - Apr 2006 - Could cloned filesystems appear under .zfs or make new autofs entries on client?

Hi,

I have an NFS build server that we are migrating to zfs.  Besides
migrating just the data we want to rethink our working practices
to make use of snapshot and cloning features.  In the way of cloning
I want to keep a prebuilt ON workspace for each of sparc/i386
which I can clone ready to do some work on without an initial
rebuild, for example.

I was very pleased to see that when I snapshot a zfs filesystem on the
server that it appears in the exported .zfs directory without the
need to remount or anything similar.

However the same cannot be said for cloned filesystems, since they have
appointed mount points.  Certainly a newly cloned filesytem is
automatically shared via nfs, but you are unable to see it
if you have already triggered the autofs mountpoints for
that hierarchy.

Avoiding our convoluted automounter maps this is illustrated via
the /net -hosts map.  On the server I have:

server# zfs list
NAME                   USED  AVAIL  REFER  MOUNTPOINT
tank                  39.7G  1.10T  9.50K  /tank
tank/u                39.7G  1.10T     9K  /tank/u
tank/u/gavinm         39.7G  1.10T  39.7G  /u/gavinm

And suppose I am already working in /net/tb2.uk/u/gavinm
(so autofs has created autofs triggers for all the dfshares
at this time).  Now I can create a snapshot and it appears
straight away in .zfs:

# zfs snapshot tank/u/gavinm at 1

client:/net/tb2.uk/u/gavinm ls .zfs/snapshot/1
bsfma       chph3       fma         lost+found  old_usr

Great.  But now clone a filesystem (I''ll base it on the above
snapshot but it could be any):

# zfs clone tank/u/gavinm at 1 tank/u/gavinm/cloned

Now I have:

# zfs list
NAME                   USED  AVAIL  REFER  MOUNTPOINT
tank                  39.7G  1.10T  9.50K  /tank
tank/u                39.7G  1.10T     9K  /tank/u
tank/u/gavinm         39.7G  1.10T  39.7G  /u/gavinm
tank/u/gavinm at 1       36.5K      -  39.7G  -
tank/u/gavinm/cloned    36K  1.10T  39.7G  /u/gavinm/cloned

But of course it does not show up in the already-mounted /net:

client:/net/tb2.uk/u/gavinm ls
bsfma       chph3       cloned      fma         lost+found  old_usr
client:/net/tb2.uk/u/gavinm ls cloned/

It sees the mountpoint in the underlying f/s but not the new f/s.

With /net I can use the old trick of /net/TB2.uk etc but that gets old
quickly.  With auto-direct/auto-indirect maps you can''t do that.

So is there a suggested way of approaching this?  Am I missing some
trick that makes the autofs stuff discover new filesystems?

Thanks

Gavin

Gavin Maltby wrote:
> But of course it does not show up in the already-mounted /net:
> 
> client:/net/tb2.uk/u/gavinm ls
> bsfma       chph3       cloned      fma         lost+found  old_usr
> client:/net/tb2.uk/u/gavinm ls cloned/
> With /net I can use the old trick of /net/TB2.uk etc but that gets old
> quickly.  With auto-direct/auto-indirect maps you can''t do that.
> 
> So is there a suggested way of approaching this?  Am I missing some
> trick that makes the autofs stuff discover new filesystems?
No, autofs is not able now to rescan its maps to notice new items.
It is something that hurt enough before, and will hurt more with
ZFS clones.  Fortunately, ZFS snapshots work better, since they are
not represented as new filesystems, but as directories whose files
have more exotic filehandles.

There are a couple of fixes for this; with NFSv4 we could just
mount the root of the filesystem and discover other filesystems
as we cross into them, which requires new functionality we call
"mirror mounts" in the NFSv4 client.  We could also fix this in
autofs for earlier versions by permitting the kernel to refresh
its map entries.  I can''t say when we''ll get to either fix. 
The
best workaround right now is ''svcadm restart autofs'', which is
also ugly.  The only consolation is that a restart doesn''t unmount
busy filesystems.

Rob T

On Tue, Apr 11, 2006 at 08:56:08PM +0100, Gavin Maltby
wrote:
> However the same cannot be said for cloned filesystems, since they have
> appointed mount points.  Certainly a newly cloned filesytem is
> automatically shared via nfs, but you are unable to see it
> if you have already triggered the autofs mountpoints for
> that hierarchy.
I posted on this the other day in some other thread.

Basically, what we need here is NFSv4 client support for client-side
crossing of server-side mountpoints.

The NFSv4 protocol allows clients to detect server-side mount points,
see, and so smart clients can cross server-side mount points and
automatically create corresponding client-side mount points.

The Solaris NFSv4 client isn''t that smart yet, so for the -hosts
special
automount map Solaris still depends on use of the NFSv3 MOUNT protocol
to detect filesystem hierarchies, and these are mounted altogether,
once, when the top any such hierarchy is automounted through the -hosts
special map.  Needless to say, the automounter does not poll the MOUNT
server for updates, it doesn''t try to keep -hosts-mounted hierarchies
up
to date.

I''m told this feature is in the works...
> With /net I can use the old trick of /net/TB2.uk etc but that gets old
> quickly.  With auto-direct/auto-indirect maps you can''t do that.
Plus the number of aliases for a server is not usually very large, so at
some point you have to resort to umount -f or rebooting to see updated
filesystem hierarchies through /net.
> So is there a suggested way of approaching this?  Am I missing some
> trick that makes the autofs stuff discover new filesystems?
Not to my knowledge.

Nico
--