Thank you for responding. You win a gold star for actually reading my email and not jumping to conclusions (-:
--- Tristan Ball <[EMAIL PROTECTED]> wrote: > I think the 7580 might be a mistake. The card has > only 2meg of cache (read: f*ck all). The amount of RAM is not an apples-to-apples comparison. The RAM isn't SDRAM like on other hardware RAID cards but SRAM... no latency, and the controller uses a non-blocking switched fabric.* I'm too tired to remember what that means, but we saw that the 3ware cards did about as well as other RAID cards with much more RAM. I don't recall, however, looking over RAID 5 performance (regarding your next reply), which could have been our mistake. Still, the primary problem is corruption, not performance, but they could be related. * Something about that here: http://www.matrixlist.com/pipermail/pc_support/2002-July/001737.html > Raid 5 writes are _slow_, with 4 physical IO's > required for every 1 io > from the OS or client. Thats why they try to buffer > them up and write full > stripes at a time, or to keep parity blocks cached > in ram. That means if your > clients are sending lots of small-ish random writes > (I bet yours would be if > they are DB developers), that 5 disk array will > probably sustain no more than > about 100-200 writes a sec. Only a scratch more > than a single disk. You could be right here. The author in the link above indicated that it might be a problem with small RAID 5 random read/writes. Know how to see I/Os/sec on Linux, by chance? Bonnie++? I'm still learning about Linux through experience, reading, and asking questions (: The biggest problem is not performance but corruption, but they could be related. Anyway, if the problem is the card, we should see the same problem when we put NT on the server. I'll let you and the list know. > You also didn't mention what the CPU utilisation > looked like, particularly as a > user/system/io breakdown. :-) Load averages < 0.50 most of the time, free memory - caches + buffers is around 350MB out of 2GB. sysctl.conf has been tuned for a large file server setup using recommendations from "Securing And Optimizing Linux 2.0" (only in hardback from OpenNA.com). I can post a copy of the file if you'd like. I'm still learning about Linux.. how would a user/system/io breakdown be done? Some flag of ps? > Actually, while they can improve performance, they > are an inherently less > reliable option than no-oplocks. Even on pure MS > networks there are special > cases where they can cause trouble. (it does require > other things to go wrong to > trigger them tho). So.. it is safe to turn them off? > I generally find level 3 debugs are the lowest level > usefull for tracing, but > that enabling them for all processes will massively > affect performance - > particularly if your logs go to that raid-5 volume > :-) Seperate drive for the OS + logs. I'd heard level 3 was too slow so I didn't go that high. I'll take it up that high on a client basis using your next advice. > I generally selectively enable logs using smbcontrol > for particular clients, and > use a level of 3-5. We couldn't determine how to set the debug level individually. Thanks! > > veto files = /lost+found/ > > This will slow performance. Our problem wasn't performance but corruption, but they could be related. I'll take this option out as it doesn't matter if the user sees those directories. Thanks for catching that. > > debuglevel = 2 > > Again, this will affect performance. It was on 1 most of the time but on 2 when I copied it to the list. > Sorry you had such a rough time of it tho.. Thank you very much! There is still a chance we will use Samba again for this, and I'll take your advice with me when we do. By chance, do you use ACLs? /dev/idal __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba