On Fri, 2004-05-14 at 14:22, ww m-pubsyssamba wrote: > I would strongly suspect that the Mac OS finder is simply hammering the > file server because, in your case, it as to do 10000 seperate read opertions > just to display the folder contents. Try with an NFS share, this would > identify whether the SMB support in either the client or server is > ineffecient or if you just have unrealistic expectations of performance > from this type of configuration.
We are confident that it is something goofy about the way the Finder behaves when reading the content of the directory. Doing an 'ls' on the share from the OS X command line is quite snappy. It's only when the Finder does the reads on the directory for both the files and the metadata that things slow down and we get the CPU spike. My counterpart has been doing some research and, although I've not seen the material that he is referencing, he has reported to me that Panther seems to have a few known issues with performance when it comes to accessing NFS and Samba exports/shares and he is hearing that the next version will provide several fixes in this area. I'm not an OS X user so I will have to trust him on this one. > If you are using an OS X server have you tried connected via Apple Talk > instead? This has native support for resource fork data and may give > better performance, We are not using OS X as a server. The servers are all Windows 2000 or Debian GNU/Linux stable + Samba. The client wants to completely eliminate AppleTalk from the network based on his past experiences with AppleTalk performance. Thanks for your help everyone. For now, I think we are going to chalk this one up to lots and lots of files in the shares and the somewhat goofy way that the Finder handles directory listings. -- Nathan R. Valentine <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
-- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
