Decided to do a quick comparison of AFP vs SMB in 5b4

 

Have a 120GB SATA drive as Cache in my server connected to MB. Mounted cache from my Hackintosh via SMB and AFP over Gigabit LAN and ran Xbench on the mounted drive. Results below

 

 

Interestingly, AFP is significantly faster in 256K block sequential reads with SMB better in 4K block sequential writes. Everything else is pretty similar with a sligth edge to AFP across the board.

 

Peter

I think this should be moved to AFP under the 5.0 boards..

 

I've noticed some good speeds as well (will run some tests this weekend when I get some extra time).

 

One thing I did notice with AFP is that bringing up the share list when clicking on the server in the Finder takes significantly longer using AFP than with SMB. Choosing the "<name>-SMB" from the Finder shows the list almost instantly while choosing just the "<name>" results in a spinning cursor for about 20-30 seconds.

 

Stokkes, I'm not seeing such a delay.

 

I have 4 shares under AFP and 9 entities appear under SMB. There might be a slightly longer delay bringing up the AFP shares but only a second or two, not the 20-30 you note.

 

I see the same thing Stokkes. Connecting to the server using SMB populates the shares almost immediately, however connecting to the bonjour afp share takes 20-30 sec to populate the share list. I am running the cache script as well, it appears that script has no bearing on AFP as I can hear each drive spin up as it is waiting to populate the shares.

 

Below are my results using Xbench:

 

I have done some real world testing as well

 

Test Setup:

i3 iMac (10.6.6) -> 20 foot Ethernet -> Netgear Gigabit Switch -> 10 foot ethernet -> UnRaid 5b4 (i3 on Gigabyte H57M-USB3)

Cache Samsung HD502HJ (7200rpm) all other drives Samsung HD154UI (5400rpm)

3 MKV files (10.81GB total)

 

Here are the speeds I am getting:

 

SMB No Cache

 

SMB Cache

 

AFP No Cache

 

AFP Cache

 

*All Data Disks and Parity are Samsung HD154UI (5400 rpm)

I guess AFP doesn't play nice with cache_dirs then. 

It is probably more a reflection of the way AFP works.  I don't know the exact workings of AFP but I can only surmise that it is something along those lines.

That's interesting.  I wonder if AFP is requesting a file property that cache_dirs does not cache, and if so if it can be modified to cache that property?  Between the improved speed and improved time machine support I would love to start using AFP once 5.0 is out of beta but having my disks spin up every time my media server scanned for updates might be enough to prevent me from taking advantage of the AFP support.

My experience is the same as Stokkes - bringing up the shares list takes a long time using afp. I don't use cache_dirs. I have gone back to using just smb due to the long delay.

That's interesting.  I wonder if AFP is requesting a file property that cache_dirs does not cache, and if so if it can be modified to cache that property?  Between the improved speed and improved time machine support I would love to start using AFP once 5.0 is out of beta but having my disks spin up every time my media server scanned for updates might be enough to prevent me from taking advantage of the AFP support.

It is probably reading files it puts in the directories.  (all those with a leading "_" character it seems to litter the disks with)

 

If you are curious, you can install the "inotify tools" package from within unMENU.

Then, you can type:

inotifywait -mr /mnt/user

to see exactly what is being accessed.  If it is specific files, then perhaps a change in the cache_dirs program can read them too so the disks do not need to be spun up.

 

If you do not have unMENU installed, you can download the package from

http://www.slackware.org.il/slackware/slackware-12.2/slackware/a/inotify-tools-3.13-i486-1.tgz

 

move it to your flash drive. (do not un-compress it)

install it with the following command:

installlpkg /boot/inotify-tools-3.13-i486-1.tgz

(assuming you moved it to the root directory of your flash drive, otherwise, modify the path to the .tgz file as needed)

 

Joe L.

It is probably reading files it puts in the directories.  (all those with a leading "_" character it seems to litter the disks with)

 

Seems unlikely but if someone else wants to test and confirm my results it can't hurt.  I have OSX set to not create those files on my shares (which saves me having to run the cleanup script) and AFP is still far slower to initially browse for me, but once it pops up the intial finder window it browses quickly.  My first two thoughts are that OSX probably wouldn't look for files it is set to not create, and second, if it was looking for those files (which it puts in every directory AFAIK) then it would be slow to browse every directory, but for me it's only the first directory that is slow to browse.  Subsequent directories browse as quickly as SMB.

One thing I did notice with AFP is that bringing up the share list when clicking on the server in the Finder takes significantly longer using AFP than with SMB. Choosing the "<name>-SMB" from the Finder shows the list almost instantly while choosing just the "<name>" results in a spinning cursor for about 20-30 seconds.

 

I see the same behavior. I would hate to give up using AFP. Any chance on a fix for this?

Same problem here... AFP is hardly usable... Also in 5b6

Funny - I'm not seeing this issue. I've got 6 shares across 5 drives, all appear without issue. There is a longer delay, but only a couple of seconds.

hmm, not encouraging.  SMB isn't that responsive on my box,  especially on the large directories which contain probably 1500 sub-directories.