> What are the goods and bads of the different network file system mounts
> under OSX? I know AFP, NFS, and SMB are available.. which is best?
For Rush, it's best if you use a file system that remains mounted
regardless of interactive user activity, ie. if the interactive
user logs out, you don't want mounts to disappear, as this will
affect renders running in the background with Rush.
NFS seems the best choice for that, and for handling permissions.
Unfortunately NFS doesn't handle resource and data forks well
under OSX..
*** UPDATE JANUARY 2011 ************************************************************
*** Since this article was posted, Apple nfs has since been stabilized greatly.
*** In Tiger (10.4.x) and up, resource/data forks are now handled properly.
*** Apple has chosen to go the NFS route, since the other network file protocols
*** (AFP and SMB) are simply not multiuser file systems.
************************************************************************************
..it leaves behind little "._" files which work fine until the user tries
to move the original file to a different directory, without also moving
the "._" file, causing the data/resource fork association to be lost.
I advise configuring mounts to automatically be mounted on boot in OSX.
There are some articles in the rush newsgroup on this.
*** UPDATE JANUARY 2011 ********************************************************************
*** Articles I would recommend on configuring mount-on-boot:
***
*** [OSX/ADMIN] Boot script to mount multiple file servers
*** http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+1847+1847
***
*** [OSX/Admin] How to create a custom boot script to mount a file server
*** http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-viewthread+1710+1731+1783
***
*** Subject: [OSX/SYSADMIN] Example NFS setup for Rush on a small 'pure OSX' network
*** http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-viewthread+1295+1297+1298+1839
***
********************************************************************************************
Also, which network file system protocol you choose can
make a difference in speed of rendering; under OSX you have
many choices: AFP, SMB, NFS. Each has its own benefits and drawbacks.
In short:
AFP - BENEFITS: native to OSX, handles resource/data forks easily.
DRAWBACKS: some servers don't implement AFP very well, and are
suseptible to load. AFP does not handle multiuser very well;
similar to SMB, all file I/O through the AFP mount will inherit
the permissions of the user who the mount was created as.
Also, mounts may automatically disappear if the interactive
user logs out. And finally, as of Tiger (10.4) AFP became a
single-user filesystem, in that only the owner of the mount point
can access the server.. preventing multi-user access. For more see:
http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-viewthread+1013+1014+1015+1019+1020+1021+1024
NFS - BENEFITS: can be mounted on boot, and mounts will stay in place
even if user logs out (so as not to affect background rendering).
Handles multiuser access correctly; if root makes the mount,
any user can access the mount, and permissions will work normally;
files will be owned and permed by the user accessing the file,
and not by the user the mount was created as.
DRAWBACKS: OSX uses ._XXXX files to handle resource and data forks,
which can cause trouble when users move files around at the unix prompt
with 'mv', but forget to move the ._XXXX files too. NFS may need tuning
to work efficiently with some servers. NFS uses UDP instead of TCP,
which means under high load, it may not handle throttling well.
(TCP implementations of NFS, if available, may work better for
bandwidth control)
SMB - BENEFITS: Well, if you have Windows file servers, this is often the only
way to mount them. In some cases people have reported faster file i/o
with samba than with NFS. Depends on tuning.
DRAWBACKS: not a multiuser file system; like AFP, all file I/O
through the smb mount will inherit the permissions of the user
who the mount was created as. And finally, as of Tiger (10.4) SMB
became a single-user filesystem, in that only the owner of the
mount point can access the server.. preventing multi-user access. See:
http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-viewthread+1013+1014+1015+1019+1020+1021+1024
There may be other reasons; those are ones I've run into.
[EDIT: added links re: single user access limitations of SMB and AFP -- erco 10/20/08]
|