> Idmapd doesn't currently support gid's/uid's in the names. Looks like > rfc 3530 does allow that: > > > And I don't think it would be difficult to modify idmapd to do this. >
Thats what I ended up doing (though it was a really bad hack). It was a one-liner in two sections, and it worked fine for my tests. OpenSolaris seems to handle the whole stringified UID/GID thing much better than Linux at present with the idmapd in the nfs-utils package not supporting stringified UID/GIDs, and the mapping thats done when no idmapd daemon is running on the linux client seems stupid. Anyway, that little drama aside, I've got a performance problem to deal with now. The OpenSolaris NFS server doesn't seem to perform well most of the time. I'm using NFSv4 and specify wsize and rsize of 32768 on the Linux client when mounting the NFS share. I'm not sure about read performance (haven't tested it yet), but write performance is typically about 600k/sec over a gigabit network when copying a number of (mostly small) files over to the NFS server. I tried changing the backing filesystem to UFS instead of ZFS but it didn't seem to make any difference. I also swapped the drives into another machine which is about twice as fast and with about twice as much RAM, still no difference. Load wasn't a problem on either end though, so it was a stab in the dark. Is there anything I can do to improve the write performance in this situation? One thing I did notice is that if I create a file full of nulls (eg. using dd if=/dev/null of=/mnt/nfs1/test.img ...) and then format the file to ext3 (mkfs.ext3 /mnt/nfs1/test.img) and then mount the file locally on the client (mount -o loop /mnt/nfs1/test.img /mnt/nfs2), and then copy the same files to /mnt/nfs2, the performance of the NFS server is around 30MB/sec. -- Regards, Robert Davidson. Obsidian Consulting Group. Ph. 03-9355-7844 E-Mail: support at obsidian.com.au
