Hi Volker,John, folks I upgraded the smb binaries to 3.0.24 and reduced the log level and my samba servers now giving throughputs of 32-38 mbps with some spikes beyond 60mbps .
That's way below what John's getting. Anyway, I can at least finish off this installation as my samba server can match or exceed the clients benchmark against his existing MS windows server. Since I am using 3 X 1 terabyte disks in a hardware raid 5 array disk I/O should not be an issue. I expect the issue to be too may patch points (the joy of structured cabling) or not too good switches. I will be looking at optimisations to further improve throughput. Volker's 700Mbytes/second on 10Gbe sounds good and could be considered for the client interconnects for lustre. I've got to work out the cost of cabling and switches for 10g. That could be a deterrent. Else, putting in 1 10g nic should be equal to putting in three or four 4 port GBe Nics. John, I will keep you posted on my work on Lustre. I expect to start work on it in about 10 days. We could share some info on optimising CTDB to take advantage of the high I/O provied by Lustre. SAN using opensource and COTS seems a very interesting proposition if the client interaction can be done via smb protocol, especially if the throughputs are scalable. I am also interested in PNFS (NFSV4) but again its available only on solaris. Plus windows clients dont support nfs out of the box so it cant be considered for most of the potential clients Cheers, Godwin > On Fri, Mar 13, 2009 at 08:53:11PM -0500, John H Terpstra - Samba Team > wrote: >> My home network running Samba-3.3.1 over 1 Gigabit ethernet transfers up >> to 90 Mbytes/sec. The file system is ext3 on a Multidisk RAID5 array >> that consists of 4x1TB Seagate SATA drives. > > Hey, bragging time :-) > > Using one 3.2 smbclient against smbd reading off RAM disk > I've seen more than 700MBytes/second over 10GigE where the > raw TCP speed was not much more than that. > > With real client apps reading consecutive small files using > the just-added preopen module the performance was more than > 300MBytes/second. But here we had to hand-tune the server > using the preopen module to completely hide the file system > latencies. > > Executive summary: smbd is no real bottleneck, it's client > behaviour and the rest of the infrastructure that limits > you. Performance tuning to those numbers is not really easy > though, you really have to look at all components on the > path from the Win32 app down to the raw rotating disk. > > Volker > -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
