Quoting Tim Connors > I've got one for you; just came in on the mailing list (someone got stale > mounts when their kernel nfs server restarted):
>> ZFS and the NFS kernel server are not that tightly integrated. >> >> When you do a 'zfs set sharenfs="foo,bar" pool/vol' of a 'zfs >> share >> pool/vol', the zfs tools just give a call to the NFS kernel server >> saying 'Hey I want you to share this over NFS'. That's what it should do. Under FreeBSD it sends a HUP to mountd - that's it. >> >> If the NFS kernel server is restarted it unshares everything and only >> reads back whatever is in /etc/exports. This is actually expected as >> NFS doesn't know anything about ZFS. Doing a >> 'zfs share -a' exports all your NFS/SMB shares again. Yes, it is a dependency. In general /etc/init.d or /etc/rc.d .. scripts take care of it so there is room for improvement if it is not done yet. >> When you don't use your system native tools, or when someone tries to >> solve something at the wrong layer (zfs trying to mess around with >> NFS? It uses - it just has another list as /etc/exports. It's not a big deal, I would think. ZFS changes the way to work with filesystems in may ways. Who would create/clone/destry/move around filesystems as I do with ZFS now? I have 164 ZFS filesystems on the system I just queried. It makes sense to keep the list of exports here. On a ZFS system, /etc/exports is a "legacy file". BTW: the ZFS hierarchy gives you better control access to parts of the directory than on other filesystems, because it is easy to create a new ZFS for a directory tree and give it different export options. Regards Peter _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
