> I encountered an issue that people using OS-X systems > as NFS clients > need to be aware of. While not strictly a ZFS issue, > it may be > encounted most often by ZFS users since ZFS makes it > easy to support > and export per-user filesystems. The problem I > encountered was when > using ZFS to create exported per-user filesystems and > the OS-X > automounter to perform the necessary mount magic. > > OS-X creates hidden ".DS_Store" directories in every > directory which > is accessed (http://en.wikipedia.org/wiki/.DS_Store). > > OS-X decided that it wanted to create the path > "/home/.DS_Store" and > it would not take `no' for an answer. First it would > try to create > "/home/.DS_Store" and then it would try an alternate > name. Since the > automounter was used, there would be an automount > request for > "/home/.DS_Store", which does not exist on the server > so the mount > request would fail. Since OS-X does not take 'no' > for an answer, > there would be subsequent thousands of back to back > mount requests. > The end result was that 'mountd' was one of the top > three resource > consumers on my system, there would be bursts of high > network traffic > (1500 packets/second), and the affected OS-X system > would operate > more strangely than normal. > > The simple solution was to simply create a > "/home/.DS_Store" directory > on the server so that the mount request would > succeed.
Too bad it appears to be non-obvious how to do loopback mounts (a mount of one local directory onto another, without having to be an NFS server) on Darwin/MacOS X; then you could mount the /home/.DS_Store locally from a directory elsewhere (e.g. /export/home/.DS_Store) on each machine, rather than bothering the server with it. This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
