Robert Thurlow wrote: > Anthony J. Scarpino wrote: >> I'm not sure if this is an nfs/autofs problem or zfs problem... But I'll try >> here first... >> >> On our server, I've got a zfs directory called "cube/builds/izick/". In >> this directory I have a >> number of mountpoints to other zfs file systems.. The problem happens when >> we clone >> a new zfs file system, say cube/builds/izick/foo, any client system that >> already have >> cube/builds/izick mounted, can see the new directory foo, but cannot see the >> contents. It >> looks like a blank directory on the client systems, but on the server it >> would be fully >> populated with data.. All the zfs file systems are shared.. Restarting >> autofs and nfs/client >> does nothing.. The only way to fix this is to unmount the directory on the >> client, which >> can be invasive to a desktop machine.. >> >> Could there be a problem because the zfs files systems are nested? Is there >> a known >> issue with zfs-nfs interactions where zfs doesn't tell nfs properly that >> there has been an >> update, other than the just the mountpoint? thanks... > > This is a known limitation - you would need to add entries to your > automounter maps to let the client know to do mounts for those > 'nested' entries. We're working on it - since the client can see > the new directories and detect that they're different filesystems, > we could do what we call 'mirror mounts' to make them available. > See http://opensolaris.org/os/project/nfs-namespace/ for more on > this and other work. > > Rob T
Ok... thanks for the link.. I'm happy this is known and being worked on.. Any targets yet when this would integrated? thanks.. Tony This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
