Pleas excuse me if I sound somewhat "stupid". I really do mean this as a question. What is so much better or "awesome" about Apple's Software RAID when compared to Linux or any other UNIX ? Where I come from Software RAID always gives us the creeps :) Especially with cheap software raid controllers ofr IDE(SCSI and SATA out in the wild. :)

[ Reply to This | # ]

Fair question/comment. SW RAID should give you the creeps :) For a proper server, hardware RAID is the way to go. My "other" server running Linux has a SCSI MegaRAID controller w/ 220GB of RAID5. That's the one I spent someone elses money on :) For home my boss went with hardware ATA RAID (Adaptec 2400A) under Linux. My setup is two 120GB IDE drives in an external firewire enclosure configured for RAID 1 (mirroring) through software on 10.3.3. My main goal was having somewhere safe to put work documents that I could always get to via SMB. I wasn't too interested in performance but recovery time of < 15 minutes in the event of a server problem was critical. Here's how OSX's SW RAID helped me solve this (AKA what I like about Apple's SW RAID):

Cost of controller $0. For performace the drives should be split across controllers but $0 is still $0. Given the cost of huge IDE disks (50 cents per gig) I'd suggest that everyone buy a matched pair of drives and a FW enclosure ($54 @ Compgeeks) and use that for storing data on. DDS3/4 media runs around 25-50 cents per gig and the drives are around $800. Plus you have to actually do the backups!

Perfect support fot for Firewire. Having moved to FW I will no longer tolerate shutting down a box, unscrewing the case, fiddling with IDE cables and double checking jumpers - or being one power connector short and having no Y cable. This is more of a FW versus non FW issue and if you're not changing your drives often (which you shouldn't be) this may be moot. But my hardware effort if I have to switch boxes is < 60 seconds. I'm not up to date on FW support for the various *nix flavors but I'd guess doing RAID with a PCMCIA FW controller (when I travel I sometimes take the RAID with me) would require careful kernel & driver choices.

Apple's SW RAID is vendor supplied out of the box. In the event of a BIG server failure I don't have to run and build a *nix box with an identical config and then do the associated hardware transplants. Or wait for a new controller to be FedExed. Further, I can take my FW RAID enclosure over to a friend's and it works without the inevitable "No, I'm running (FreeBSD|OpenBSD|Linux) not (..)" or any other SW incompatibilities. AFAIK Windows only supports SW RAID on the server versions, not workstation.

Performance! See http://www.barefeats.com/fire26b.html They seem very bizare results but that site does a lot of benchmarking and I _think_ they know what theyre doing. While I'm doing mirrored SW RAID to FW on one controller and performance isn't my bag the numbers do show that Apples SW RAID sometimes outperforms HW RAID.

While it's not right for everyone it was very painless to do.

-m

[ Reply to This | # ]

Agreed. Further testing showed that the config from my original post actually decreased performance in some cases. Use these instead. -m

[ Reply to This | # ]

Just a reminder that the aforementioned 'Using Samba' book is actually included as part of the standard Samba documentation set. If you're running 10.2 or 10.3, there's actually a copy of it already on your HD.

Open a browser and go to (note the three slashes):

file:///usr/share/swat/using_samba/toc.html

NOTE:This is not my tip -- I first read it here
Of course, O'reilly is a great publisher and if you're really into messing with Samba, you may want to support them and buy the dead-tree version anyway..

[ Reply to This | # ]

Should these options be used instead of everything in the originial post, or should we still use "read size" and "getwd cache" as well as the new "socket options"?

That is, should we use the following:

read size = 1024
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_SNDBUF=8576 SO_RCVBUF=8576
getwd cache = yes

[ Reply to This | # ]

I bumped the "read size" to 16384, as well. This value needs to be selected with some intelligence. I experimented with values like 4096, 8012 until things "felt" right. One should really measure the throughput properly when tweaking this value. See this Samba performance tuning reference. 16K is a pretty standard setting for BSD boxes.

I did not change the "getcwd cache" value from it's default .

According to Using Samba:

This global option specifies whether Samba should use a local cache for the Unix getwd() ( get current working directory) system call. You can override the default value of yes as follows:

[global] getwd cache = no

Setting this option to yes can significantly increase the time it takes to resolve the working directory, especially if the wide links option is set to no. You should normally not need to alter this option.

I've never noticed a problem accessing [homes] for any of my users.

[ Reply to This | # ]