Monday, May 21, 2012.

Site Search powered by Ajax

AFP versus SMB/Samba

Knowledge Base Article 398

Mac OS X clients can connect to network file servers using both the Apple Filing Protocol (AFP) and the Microsoft Server Message Block (SMB) protocol. (SMB is also known as Common Internet File System or CIFS). Mac OS X clients can also use other protocols such as NFS and FTP.

afp-smbOS X supports SMB largely because there are many environments in which only Microsoft servers are available on a network. However, SMB is proprietary to Microsoft and was designed specifically for Windows clients whereas AFP was designed by Apple for Mac OS X clients, so, in production/professional workflow environments, SMB is unlikely to be a sufficiently fast or robust solution. Apple recommends only AFP.

It is also possible to run SMB-compatible servers under Unix. A product which provides this is Open Source Samba. While Samba is a great product, it should be born in mind that the SMB protocol is proprietary to Microsoft and as an Open Source product, Samba relies on reverse-engineering the protocol. Reverse engineering means that Samba was developed not from a formal Microsoft specification but by analysing many data packets on a network and inferring the protocol. Hence, its successful implementation depends upon the unlikely scenario that the developers having catered for every packet contingency.

While Samba is useful for Windows clients that wish to access a Unix file system, it is not recommended as Mac OS file-sharing solution. Effectively, Mac OS file system requests are being converted to SMB then to Unix. When network problems occur, it can be extremely difficult to isolate a reverse-engineering issues from problems due to an incompatibility between AFP and SMB. The situation can become untenable when attempting to share files between Macs and PCs on a single SMB or SMB+AFP server.

Last but by no means least, the performance of an SMB server with Mac OS clients is generally much poorer than native AFP servers such Mac OS X Server or HELIOS EtherShare. This is due to the SMB block size and is particularly noticeable on Gigabit networks.

In summary, these are the general issues affecting SMB file servers for Mac OS clients...

Issue
Explanation
SMB has significantly poorer read/write performance The SMB block size is limited to less than 64kb per transaction, AFP uses 128 KB by default. Starting with 10.6 clients it can be up to 1024kb.
SMB has no server Find File support A single client search can utilize the disk, CPU and network on the the server. A search of a server-based volume can takes hours (depending on the amount of files)
SMB has no Time Machine support Native AFP servers from HELIOS and Apple provide this.
SMB has no sleep suspend support AFP has sleep/wakeup protocol support which means volumes are always connected, sleeping Mac's can be observed via user lists (or swho -c)
SMB has not Spotlight search support Native AFP servers from HELIOS and Apple provide this.
SMB is less stable (more kernel panics) Overall SMB has a rather checkered code development history. In general,, Macs run more reliably and faster using AFP.
SMB has no Apple Extended Attributes Support Starting with OS X 10.4 and now intensified with 10.6, Apple uses "xattrs" to save additional information, e.g. Finder comments.
BonjourTM server and printer browsing AFP servers can be quickly browsed via Bonjour. SMB uses still WINS which is not working well.
t_u_y_k
1x1.gif
adopting_voip_article
call_us
1x1.gif
subscribe_newsletter
1x1.gif
presstore_training
1x1.gif
t_u_y_k
1x1.gif
adopting_voip_article
1x1.gif
whats_new_p4

Login Form