On Wed, 21 Nov 2007 22:36:18 +0100, Simon Gao <xzs_gao at yahoo.com> wrote:
>> Simon Gao wrote: >> > Here is one issue I am running into when setting up >> a new NFS server to share several zfs file systems. >> > >> > I created following zfs file system from a zfs pool >> called bigpool. The bigpool is the top level file >> system and mounted as /export/bigpool. >> > >> > file system mount point >> > >> > bigpool /export/bigpool >> > bigpool/zfs1 /export/bigpool/zfs1 >> > bigpool/zfs2 /export/bigpool/zfs2 >> > >> > All directories under /export are owned by a group >> called users. Also group users have write access to >> them. >> > >> > Next, I exported bigpool (zfs1 and zfs2 inherited >> from bigpool) as NFS share. >> > >> > zfs set sharenfs=on bigpool >> > >> > On a Linux client, I can mounte all shares directly >> without problem. If I mounted /export/bigpool to >> /mnt/nfs_share on the Linux client. The ownership and >> permissions >> > on /mnt/nfs_share match to /export/bigpool on the >> nfs server. >> > >> > However, permissions on /mnt/nfs_share/zfs1 or >> /mnt/nfs_share/zfs2 are not inherited correctly. The >> group ownership is switched to root on >> /mnt/nfs_share/zfs1,zfs2 and write permission is >> removed. I expect /mnt/nfs_share/zfs1 should match >> /export/bigpool/zfs1, so does for zfs2. Why ownership >> and permissions do not get inherited? > > I actually cd into the directory and tried creating files. But It did not > work. Looks NFS v3 or maybe NFS v4 >does not cross file systems > automatically. After mounting /export/bigpool, one has to mount > /export/bigpool/zfs1 >to see the real directory on a client. So there are > two mounts to do to get to /export/bigpool/zfs on the client >side. The > deeper directory tree gets, the more mounts one has do on the client side. that is correct, the client presents you the pseudo namespace from the server that the server has build on order to present all the real share points, i.e. '/export/bigpool/zfs1' and '/export/bigpool/zfs2' '/export/bigpool' is not a shared file system, it's the zpool that contains the 'zfs1' and 'zfs2' file systems. and yes, the client usually does not cross server file system boundaries unless the client implements 'mirror mounts', note this is a purely client releated item and has nothing to do with the server itself. the solaris v4 client worked the same until recently when we implemented 'mirror mounts' as Robert already pointed out. >> Are you using NFS v3 or NFS v4? >> >> In either event, you could get packet traces >> corresponding to the events >> to see what it is flowing >> across the wire. I.e., you don't know enough right >> know to be blaming >> the server, whether it is >> for NFS or ZFS. > > I am using NFS v3. I don't believe I am the only one or first one running > into this problem. I would like toknow how others deal with such problem. > Using OpenSolaris is not an option in our production environment. it is being dealed with by either using an automounter or an NFS client that is capable of 'mirror mounts', the Solaris v3 client is not, the Solaris v4 client is now able to perform 'mirror mounts', ie. cross file system boundaries on the server by automatically mounting them into the clients namespace. I also believe there are a couple of Linux V4 implementations that already do implement 'mirror mounts' as well. > Without being able to use sub file systems easily, I will be forced to use > one big file system without a quota utility that can report each user's > usage. That's a real hindering thing. I really wish Sun can put the > traditional quota utility back. > > Simon >This message posted from opensolaris.org > _______________________________________________ > nfs-discuss mailing list > nfs-discuss at opensolaris.org -- frankB PS: Gutes Posting. Philosophisch und so weiter... Excellent posting. Philosophic and so on...
