[Samba] SMB throughput inquiry, Jeremy, and James' bow tie
I went to the site to subscribe again and ended up watching some of Jeremy's Google interviews. I particularly enjoyed the interview with James and the bow tie lesson at the end. :) So anyway, I recently upgraded my home network to end-to-end GbE. My clients are Windows XP SP3 w/hot fixes, and my Samba server is 3.5.6 atop vanilla kernel.org Linux 3.2.6 and Debian 6.0.6. With FDX fast ethernet steady SMB throughput was ~8.5MB/s. FTP and HTTP throughput were ~11.5MB/s. With GbE steady SMB throughput is ~23MB/s, nearly a 3x improvement, making large file copies such as ISOs much speedier. However ProFTPd and Lighttpd throughput are both a steady ~48MB/s, just over double the SMB throughput. I've tweaked the various Windows TCP stack registry settings, WindowScaling ON, Timestamps OFF, 256KB TcpWindowSize, etc. Between two Windows machines SMB throughput is ~45MB/s. You can see from the remarks below the various smb.conf options I've tried. No tweaking thus far of either Windows or Samba has yielded any improvement, at all. It seems that regardless of tweaking I'm stuck at ~23MB/s. [global] # max xmit=65536 # socket options=TCP_NODELAY IPTOS_LOWDELAY # read raw=yes # large readwrite=yes # aio read size=8192 nt acl support=no fstype=Samba client signing=disabled smb encrypt=disabled # smb ports=139 smb ports=445 The Linux server has an Intel PRO/1000GT NIC, the clients motherboard embedded RealTek 8111/8169, the latter being the reason I'm limited to ~50MB/s over the wire. I run nmbd via the standard init script at startup but I run smbd via inetd. This doesn't appear to affect throughput. I effect config changes with kill -HUP of inetd and killing smbd. I have Wireshark installed on one of the Windows XP machines, though I'm a complete novice with it. I assume a packet trace may be necessary to figure out where the SMB request/reply latency is hiding. ~23MB/s is a marked improvement and I'm not intending to complain here. It just seems rather low given FTP/HTTP throughput. I'm wondering how much of that ~48MB/s I'm leaving on the table, that could be coaxed out of Windows or smbd, the kernel, etc with some tweaking. I don't want to take up a bunch of anyone's time with this. If you can just tell me what information you need in order to point me in the right direction, I'll do my best to provide it with little fuss. Thanks again for providing such an invaluable piece of open source software to the world. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Hide empty Samba shares?
On 9/5/2012 9:23 AM, Sam Bulka wrote: > Stan Hoeppner hardwarefreak.com> >> >> Samba is not MS Windows. Just because a feature exists in MS Windows >> does not make it "basic" translated "expected" in other platforms. If >> you were a long time Samba/*nix user and switched to MS Windows you'd >> have the same complaint in reverse (though there are few such defections). > > Samba was initially developed by watching Windows network protocol to allow > share files btw Linux and Windows. Of course its expected to offer basic > features Windows users are used to when sharing files with Windows. Yes, of course, and it does. But you're missing the point. The feature in question isn't part of the SMB/CIFS protocol stack, thus Samba can't duplicate it. It's an operating system specific feature implemented in, and unique to, MS Windows. Microsoft controls both their SMB/CIFS code stack and their operating system code. Thus they are free to create internal proprietary interfaces between the two that provide unique functionality. The Samba team doesn't control the Linux, *BSD, AIX, Solaris, etc operating system code, so they can't simply add the interfaces to each OS that are necessary to implement what you call the "basic" functionality that Microsoft provides. It's not "basic" functionality at all, but extended functionality, as it's not part of the SMB/CIFS stack. It's proprietary. I'm guessing that due to your lack of knowledge of software development models that you didn't understand anything I just stated above. So I'll boil it down to this: If you critically need this feature, switch back to MS Windows. It will likely never be implemented in a Samba+OS stack. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Hide empty Samba shares?
On 9/1/2012 2:52 PM, Sam Bulka wrote: > When a partition mounted to a shared by Samba folder is dismounted, Mount/unmount is performed on filesystems, not partitions. > Samba keeps sharing that empty folder. It creates a security hazard, > since files can still be saved to that empty folder, and overwritten > next time (lost) when the original partition is auto mounted again to > the same folder. Its also confusing for most users to browse empty > shares - no normal person would understand why they are still there. No "normal person" would dismount a filesystem from underneath a Samba share. > is there any > reason or logic, why such basic functionality is not offered? Samba is not MS Windows. Just because a feature exists in MS Windows does not make it "basic" translated "expected" in other platforms. If you were a long time Samba/*nix user and switched to MS Windows you'd have the same complaint in reverse (though there are few such defections). -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Transfer speed
On 4/10/2012 8:17 PM, Harry Jede wrote: > On 03:06:34 wrote Stan Hoeppner: >> On 4/10/2012 9:36 AM, Volker Lendecke wrote: >>> On Tue, Apr 10, 2012 at 08:55:14AM -0500, Chris Weiss wrote: >>>> On Tue, Apr 10, 2012 at 8:53 AM, Volker Lendecke >>>> >>>> wrote: >>>>> On Tue, Apr 10, 2012 at 08:26:48AM -0500, Chris Weiss wrote: >>>>>> that's dramatic! what needs done (from a user POV) to get this >>>>>> backported into Stable distro kernels? suggestions? >>>>> >>>>> Wait until the next major releases pick it up. >>>> >>>> that's a really crappy option. in certain cases that >>>> could be 4 years from now. >>> >>> Well, if you are an important enough RH customer you might >>> be able to apply pressure. But that's a LOT of money >>> probably. Same for SuSE. Debian will likely be very >>> resistant against that kind of bribery^Wincentive. >> >> Debian already has 3.2.6 available in the stable repo: >> >> $ aptitude search linux-image >> ... >> i linux-image-3.2.6 - Linux kernel, version 3.2.6 >> ... > I don't know what is in your sources.list > > According to packages.debian.org that's not true :-) . There is > kernel 3.2.0 in backports, that's all, as usual. Ahh! You are correct. My aptitude foo was lacking. 3.2.0 is the latest. For some reason 'aptitude search' by default also apparently searches locally installed packages. I never realized that, until now. The linux-image-3.2.6 turns out to be my custom kernel built from vanilla source (I only use custom kernels). $ aptitude show linux-image-3.2.6 Package: linux-image-3.2.6 New: yes State: installed Automatically installed: no ... Description: Linux kernel, version 3.2.6 This package contains the Linux kernel, modules and corresponding other files, version: 3.2.6. Homepage: http://www.kernel.org/ -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Transfer speed
On 4/10/2012 9:36 AM, Volker Lendecke wrote: > On Tue, Apr 10, 2012 at 08:55:14AM -0500, Chris Weiss wrote: >> On Tue, Apr 10, 2012 at 8:53 AM, Volker Lendecke >> wrote: >>> On Tue, Apr 10, 2012 at 08:26:48AM -0500, Chris Weiss wrote: that's dramatic! what needs done (from a user POV) to get this backported into Stable distro kernels? suggestions? >>> >>> Wait until the next major releases pick it up. >> >> that's a really crappy option. in certain cases that >> could be 4 years from now. > > Well, if you are an important enough RH customer you might > be able to apply pressure. But that's a LOT of money > probably. Same for SuSE. Debian will likely be very > resistant against that kind of bribery^Wincentive. Debian already has 3.2.6 available in the stable repo: $ aptitude search linux-image ... i linux-image-3.2.6 - Linux kernel, version 3.2.6 ... -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Transfer speed
On 4/8/2012 8:08 PM, Azerty Ytreza wrote: > Hello, > > I have a little problem which I can't solve with Samba used under Debian > Squeeze. (version of Samba : 3.5.6) > I made a transfer speed between Samba server and a samba mount on the same > PC copy to RAM and the same file directly to RAM. > > 1. HDD to RAM => 105-115Mo/s Pure HD read speed. > 2. Shared the same HDD directory with samba and mount to "/media" locally > with (mount -t smbfs) : > Samba to RAM => 60-67Mo/s This isn't a copy to RAM. You've created a loop from/to the drive through the samba server and client. Thus, if you copy from the samba share to /media, you're reading from the HD and writing to the HD. So you're getting about 120MB/s aggregate to/from the drive. Linux buffering is likely pumping this number up a bit. Issue a sync after the copy command for flush the write to disk and you'll see a more accurate number. > 3. From a remote PC under Windows : ~60Mo/s Obviously GbE. This low throughput can have a number of causes, most dealing with network performance, not samba. > How Samba can divide by almost two the bandwidth ? (105Mo/s HDD and 60Mo/s > Samba) > > I have already changed that to Samba which have up my bandwidth from > ~55Mo/s to ~60Mo/s : > ** > socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=262144 > SO_RCVBUF=262144 SO_KEEPALIVE > min receivefile size=16348 > use sendfile=true > aio read size = 643638 > aio write size = 643638 > aio write behind = true > dns proxy=no > ** Are you using jumbo frames? Which NICs? Which GbE switch? Using FTP client on Windows PC, what is your GET transfer rate from the Samba machine? If it's less than 80MB/s you may have a network problem. If it's over 90MB/s you may still have some Samba tuning to do. BTW, 60MB/s from Samba to Windows over GbE is pretty damn good. Many people can't get over 35-40MB/s with Windows/GbE and Samba > Someone have an idea how I can increased speed of Samba to almost 100Mo/s ? > (I can understand than the 10% is lost by different protocol but 40-50% no > :( ) > 10Gbits should come and can't sustain 1Gbits ? :( Assuming your future 10GbE network is configured and tuned perfectly, you'll need a disk that can push over 1,000 MB/s sustained data rate to fill the 10GbE pipe. This requires either a large striped array of spinning rust (more than 14 SATA disks in RAID0), or a smaller array of fast SSDs (4 in a RAID0). -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba/GPFS/GlusterFS
On 11/21/2011 1:51 PM, François Legal wrote: > In my company, we have 2 > distant facilities, with people at each facility working on the same > files. > > The 2 facilities are connected through MPLS with about > 10MBytes/s BW. > > Saving the work files to servers located at one or the > other facility has became a pain for the people accessing the files from > the remote site. > > Trying to improve files availability, I was wondering > if a setup based on GPFS/GlusterFS plus samba for serving the file would > be a good reply to this problem. If only 2 sites, and never more, DRBD+GFS2+Samba may be a good solution. See: http://www.drbd.org/ With this setup all clients at both sites see the same filesystem (GFS2) through Samba, but their file access is always to the local server's disks. DRBD transparently mirrors the disk blocks between the two servers. I'd only consider this DRBD under two conditions: 1. If that MPLS pipe is rock solid all the time. 2. Workload is NOT writing many large say 100MB+ files regularly -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] 3.6/SMB2.0 and NT6.0 (Vista/W2K8 not-R2) question
On 8/23/2011 11:27 AM, starli...@binnacle.cx wrote: > Hello Samba Team, > > Have a W2K8 not-R2 (NT6.0) server that compiles code > served from a CentOS 5.6 server running Samba 3.5.5 > over an Infiniband link. > > Works nice but an 'imake' step that grinds through > every source file several times takes ten-to-twenty > times longer than when it runs locally on the Linux side. > > It's apparent that the entire source tree is cached > in memory by Linux, but that the Windows side retrieves > every file over-and-over again, a process that uses > more CPU than anything else so that's the bottleneck. > > Windows oplocks seems like the answer to improving > performance as it would allow the Windows server > to cache the files as well. > > From the MS documentation, it appears there might be some > oplock support in their SMB 2.0 client. Is this the case? > Any chance that oplock-based caching of files that are > only read will happen on the Windows side if we install > Samba 3.6 and enable SMB2? > > Also, we disable kernel oplocks in Samba because the > Linux kernel fakes the NFS-visible modification timestamp > of files that Samba oplocks for the duration that the > locks are held. This causes spurious rebuilds by > Linux and Unix NFS clients when the code is rebuilt > at the same time. > > Does setting "kernel oplocks = no" in Samba 3.6 interact > with the SMB2 oplock feature? I.E. does it disable > SMB2 oplocks? If these client machines have enough excess RAM to cache the entire tree and execute builds, why aren't you instead simply copying the tree files from the server to a local RAM disk, building, then pushing the result files back to the server? Massaging your current scripts to do this should be trivial. You'll get fully consistent run times to boot. Sure, it's not as 'convenient' as a remote shared filesystem acting like a local non-shared one, but then again they never really have, and never will, fully act as such. WRT convenience, once the scripts are rewritten it's a non issue. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] problem win 98 can not connect to samba
On 8/9/2011 1:53 AM, Edward Hari Purwonugroho wrote: > Dear all, > > I have problem when trying to connect samba file sharing from win 98 > but it successfull using win xp and linux. > Samba server is member domain of windows 2003 active directory. > Samba server using Ubuntu Ubuntu 10.04.2 LTS 64 bit, Samba version 3.4.7 Nothing you found in your Google searches helped? -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Cannot see linux machines from XP
On 8/7/2011 1:26 PM, Al Schapira wrote: >> What is the result when you map a Samba share from the Windows command line? > > 1) The result of trying to add a share on XP is as follows:" > "Add a network place" --> > "Select a service provider" --> > "Choose another network location" --> next > "ADS2/other" > "The folder you entered does not appear to be valid. Please > choose another." > same message for any other shared files on ADS1 or ADS2 (which > are visible from each other.) Note I said "Windows command line". If you don't know what something is, ask, or Google it. People on this list have a finite amount of time to help others. Please don't force us to waste our time teaching you the mere basics of system administration. You need these skills merely to troubleshoot. They won't get you the answer, but they help you find the eventual answer, which is why I asked you to perform this step. Google for "windows command line" and Google for "net use". > 2) The result of turning off the firewall (Norton 360) is no change to > the above problem. But under Norton 360, the machines ADS1 and ADS2 DO > appear in its network browser with status ON-LINE. But aside from this, > no other XP utility can see ADS1 or ADS2. Hence the problem. That remains to be seen. You haven't tried any of the smb/cifs command line utilities yet. And apparently you haven't looked for errors in the Event Viewer, you know, that place where Windows writes log information, tells you about problems on the machine? Error messages often point one to other information that helps him/her solve a problem. You state Samba seems to work perfectly on the Linux machines. And the Linux machines seem to access shares on the XP machine just fine. Thus, this sounds like you definitely have a problem on the Windows machine. This is the Samba list. I suggest you also ask for help on some Windows forum(s). Best of luck, -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Cannot see linux machines from XP
On 8/6/2011 9:15 AM, Al Schapira wrote: > Stan, Please reply-all as your message didn't go to the list. There are folks far more knowledgeable than me who are watching this thread, waiting to hop in after all the grunt work is out of the way. > Thank you for your reply. Searching for computers on DRS2 (XP) for ADS1 or > ADS2 'seems' to find them, > but clicking on either results in a message that the server does not permit > the operation. > It does NOT display the shares on either. Ok, that's a good sign. > ADS1, ADS2 do NOT show up in my network places, or in workgroup computers, or > in "entire network'. > The 'entire network' does show the workgroup (GAMMA5), but this only contains > DRS2 (itself). > But, as I said, ADS1 and ADS2 can see AND ACCESS files on all three computers > including DRS2. Then the problem is apparently with XP. Or, you don't have Samba properly configured to play nicely with XP, or specifically the way you want it to (purely guest access). Disable the XP firewall if it isn't already. What is the result when you map a Samba share from the Windows command line? -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Cannot see linux machines from XP
On 8/5/2011 7:59 PM, Al Schapira wrote: > I would really appreciate suggestions. Thanks. >> Where do I start to solve this? Here's a novel idea: check your logs, on both Linux and XP hosts. In addition, what is the result of? 1. Right click on My Network Places 2. Select "Search for Computers" 3. Enter "ADS2" and hit enter Do you receive "no results to display", or do you see the shares on ADS2 but receive an error when attempting to access them? -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Very slow samba performance on Centos 6
On 8/4/2011 1:11 PM, vg_ us wrote: > cifsfs mounts are really slow, so what happens when linux, windows and > mac clients map/mount the share? Are they gonna be this slow? Any way to > speed it up? Unfortunately I don't have an answer to the slow mounts issue. However, you're showing a peak performance of only about half line speed with FTP, which tends to demonstrate your system is in need of overall performance tuning for 10 GbE. Reading, digesting, and using the information in the following article may get you much closer to the ~1GB/s mark of which 10GbE is capable. http://www.redhat.com/promo/summit/2008/downloads/pdf/Thursday/Mark_Wagner.pdf If tweaking these things can double your raw network and FTP throughput, it should do similar for Samba, which would mean ~94 MB/s for cifsfs mount ramdisk-to-ramdisk or to disk. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Lighttpd + Samba for read/write?
On 8/2/2011 8:41 AM, Gilles wrote: > On Tue, 02 Aug 2011 02:11:49 -0500, Stan Hoeppner > wrote: >> As I stated, I am running lighttpd with a non-root user owning the >> docroot, have been for years > > Thanks for the info. Turns out there already was a UID "www-data" in > /ec/passwd, and lighttpd.conf used that UID by default. > > However, when creating a new text file in /var/www, its access rights > are 744, which doesn't make sense for a non-executable file: > > === > # ll /var/www/ > total 16 > drwxr-xr-x 2 www-data www-data 4096 2011-08-02 15:35 ./ > drwxr-xr-x 14 root root 4096 2011-08-01 14:35 ../ > -rw-r--r-- 1 root root 3562 2011-08-01 14:35 > index.lighttpd.html > -rwxr--r-- 1 www-data www-data4 2011-08-02 15:35 test.txt* > === > > The smb.conf documentation mentions "create mask", but how can I tell > Samba to use a different mask depending on the type of the file > (executable and non-executable)? Reference your [homes] section of smb.conf to answer your first question WRT masks. WRT the 2nd question, XP will execute a Windows binary file residing on a Samba share whether the UNIX execute bit is set on the file or not. The execute bit is only required if you want the Samba host itself to be able to execute a UNIX binary. This is the behavior on my systems anyway. If you really desire the latter, I'm not sure how to achieve it. In my case, in the rare instances where this has been needed, I simply ssh into the Samba box and perform a "chmod +x ". How often are you going to copy UNIX binaries from an XP machine into a Samba share, and then execute said binary on the Samba host? -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Lighttpd + Samba for read/write?
On 8/1/2011 7:50 PM, Gilles wrote: > On Mon, 01 Aug 2011 11:22:13 -0500, Stan Hoeppner > wrote: >> After you change ownership to www-data:www-data, use chmod to allow >> desired users to write the directory. Without this step only the >> www-data user can write. > > Thanks for the tip. I'll see if Lighttpd is OK with a non-root user > owning its docroot direcotyr. As I stated, I am running lighttpd with a non-root user owning the docroot, have been for years. It's the Debian lighttpd setup default to have www-data own /var/www and lighttpd executing as the www-data user. Examine your /etc/lighttpd/lighttpd.conf for the Ubuntu defaults. Note that this is all configurable. One could create a user:group "santa-claus:santa-claus", give him ownership of /var/www, and modify lighttpd.conf to run as user "santa-claus:santa-claus". However, doing something like this may cause problems with other distro packages that might expect these things to be the default values/locations/permissions. Keep this in mind if something doesn't work after switching to www-data. Probably worth reading the Ubuntu docs WRT lighttpd. /var$ ls -la ... drwxrwx--- 2 www-data www-data 4.0K Aug 2 01:22 www I use 770 permissions. ~$ aptitude show -v lighttpd Package: lighttpd State: installed Automatically installed: no Version: 1.4.28-2 /etc/lighttpd$ grep www-data lighttpd.conf server.username= "www-data" server.groupname = "www-data" -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Lighttpd + Samba for read/write?
On 8/1/2011 8:31 AM, Erwan Leroux wrote: > 2011/8/1 Gilles : >> On Mon, 01 Aug 2011 08:03:11 -0500, Stan Hoeppner >> wrote: >>>> By default, /var/www is owned by root.root, while Samba tutorials I >>>> read usually prefer to use nobody.nogroup. >>> >>> You sure about that? On Debian the owner of /var/www is www-data. >>> Ubuntu is derived directly from Debian. I'd be surprised if it's that >>> different. >> >> Yes, it is (installed through apt-get): > > I think most of the tutorials advise you to change from the default > root:root to www-data:www-data on this folder because this way you > have a user dedicated to the web server. After you change ownership to www-data:www-data, use chmod to allow desired users to write the directory. Without this step only the www-data user can write. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Lighttpd + Samba for read/write?
On 8/1/2011 7:41 AM, Gilles wrote: > Hello > > On a Ubuntu host, I'd like to be able to read/write files in > Lighttpd's /var/www from XP. I have Debian+Lighty+XP. > By default, /var/www is owned by root.root, while Samba tutorials I > read usually prefer to use nobody.nogroup. You sure about that? On Debian the owner of /var/www is www-data. Ubuntu is derived directly from Debian. I'd be surprised if it's that different. > How should I configure things so that Lighttpd and Samba work well > together in read/write mode? > > Thank you. May not be the perfect way to do it, but this has been working for me for quite some time: [www] path=/var/www browseable=yes writeable=yes fstype = Samba nt acl support = no valid users = stan admin users = root This is with a workgroup setup, not domain. Works fine. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] filesystem of choice?
On 6/27/2011 12:42 AM, Christ Schlacta wrote: > just requires some special consideration. I still install through > apt-get install, and it works flawlessly. it's much like a lot of > driver packages where you still have to compile them to make them work, > it just does it auto-magically. If these instructions are current http://zfsonlinux.org/spl-building-deb.html then you are portraying the process as being much simpler than it really is. The real power of ZFS is with very large JBODs, or multiples of same. When you state it works "flawlessly", how many disks are you talking about? What features have you actually tested? Or do you simply have a single disk formatted with ZFS? I'm guessing most folks here actually interested in ZFS aren't the single disk crowd, and want to know if ZFS Linux is working flawlessly with real storage. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] filesystem of choice?
On 6/26/2011 5:13 PM, Jeremy Allison wrote: > On Sun, Jun 26, 2011 at 01:09:38AM -0700, Christ Schlacta wrote: >> ZFSonLinux is very nearly production ready, and I'm preparing to >> deploy it soon on a home server. Just a few minor niceties missing >> for now, but all the essential features are in place, and the bugs >> are only trickling in and nothing major's come up in a while. >> >> I'd certainly not trust it to a ~100TB multi server multi SAN >> environment yet, but soon~ zvol has been there from zfs for a >> while, so if you want xfs on ZFS in your environment, that's the >> closest I'd trust it in production yet. > > Is this the ZFS port to the Linux kernel ? If so it's interesting > but rather limiting as the CDDL license makes it impossible for > anyone to distribute as a combined work - rules out adoption by > and Linux distros or commercial entities for example :-(. > > Shame, really does seem like a nice filesystem. Exactly. What puzzles me is that Oracle released BTRFS under GPL. Oracle now owns ZFS as well. Why aren't they GPL'ing ZFS for full inclusion in Linux, and filesystem licensing consistency? Do they fear this eroding SPARC box sales? Other market forces have almost killed SPARC already so I can't see that as a legitimate concern. Ellison obviously has some $$ reason for not GPL'ing ZFS, whether based in market reality or not. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] filesystem of choice?
On 6/26/2011 3:09 AM, Christ Schlacta wrote: > ZFSonLinux is very nearly production ready, and I'm preparing to deploy > it soon on a home server. Just a few minor niceties missing for now, > but all the essential features are in place, and the bugs are only > trickling in and nothing major's come up in a while. I think your personal definition of "production ready" is very different from that of most folks WRT their production servers. Case in point, from: http://zfsonlinux.org/faq.html "The ZFS code can be modified to build as a CDDL licensed kernel module which is not distributed as part of the Linux kernel. This makes a Native ZFS on Linux implementation possible if you are willing to download and build it yourself." Carefully note the last sentence. Most SAs aren't going to be comfortable with such a situation, for many glaringly obvious reasons. As long as it's tied to the CDDL, requires manual installation, and has no support from distros (RedHat/SuSE), ZFS Linux will never be production ready, at least not for the majority. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] filesystem of choice?
On 6/24/2011 5:31 PM, John Drescher wrote: >>I would use 'xfs'. I believe samba was originally developed >> over xfs, so it's likely the ea-suppot and acl support has had the most >> testing there. Especially if your file server is setup with a UPS, then I'd >> strongly recommend it. If not, ext4 might be safer (with write >> through). It will be slower, but safer. >> >>With a UPS, XFS's default 'write-back', will give the fastest >> performance for large file writes (I think reads as well). It's worst >> performance is on "removing" large numbers of files, as that is pretty >> much a synchronous operation... > > I would just use ext4, it does not have the ext3 large file slowness > or xfs slowdown with lots of small files. "xfs slowdown with lots of small files" is no longer true. To be accurate, the complaint was never with "lots small files" but with metadata write performance, i.e. deleting, renaming, changing attributes, etc, of lots of any sized files--operations that saturate the log journal. This poor reputation was gained long ago because XFS yielded relatively poor performance with operations such as "rm -rf" on a kernel source tree. Such an operation is metadata write intensive and previously would bring the XFS log journal to its knees, saturating the physical IO channel(s) to the disk subsystem, creating a severe bottleneck. Today this type of operation is as fast as EXT4 thanks to Dave Chinner's ingenious delayed logging patch. It in essence pushes much of the previous journal IO operations into memory, consolidates the log writes, and thus decreases actual disk IO eliminating the bottleneck: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/xfs-delayed-logging-design.txt -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba performance
On 6/2/2011 2:24 PM, Juan Pablo wrote: > Hi Stan, > > Thanks for your feedback and suggestions! You're welcome. Let's hope they're beneficial. > The disk subsystem is composed by: > > - 8 WD2002FAEX SATA 2TB hard drives (7200 RPM, 64MB cache, 4.2 ms avg latency) > - 1 Intel RAID controller RS2BL080 with 512 MB configured with 1 virtual > drive > 12.7 TB (hardware RAID 5 with 1 MB stripe size, caches enabled, read-ahead > enabled) > > In your experience, should I expect higher performance from this hardware? That depends on your target workload(s). You're currently achieving single stream read performance of 780 MB/s, over 110MB/s per drive. That's a really good streaming read, close to peak drive read performance. The problem I see is when you have 4 readers (Win7 clients) reading 4,000 files each. If these are 16,000 unique files, not each Win7 machine reading the same 4,000 files, i.e. no cache benefit, then I don't think your disk heads are going be able to seek fast enough to service all the read requests and hit wire speed SMB. If your production load will be significantly less than this artificial test load, you may be fine. > Will try the ramdisk test you are suggesting and post back the results. > Thanks > for the suggestion! The results should be informative, one way or the other. > I have jumbo frames enabled in the switches but windows drivers for the Intel > network cards don't have the option to enable jumbo frames. I also tried > raising > the MTU in the linux server but performance was even worse (I thought this > was > related to the windows NIC driver not supporting MTUs larger than 1500). Lack of jumbo frames is probably hurting your wire performance due to increased interrupt processing and other factors. I'm surprised some Intel NICs don't support jumbo frames. Must be desktop adapters. Can you post the model# of the NICs in the Win7 PCs and those in the server so I can do some research? > I also modified windows registry to manually enable smb2 protocol because it > was > not negotiating smb2. Do you think of any other optimization that can be done > on > the windows terminals? I have no experience yet with SMB2 or Win7 so I can't really say. You should be able to tune that server and the clients to hit near wire speed with regular SMB. I suggest solving that problem first, then worry about SMB2. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba performance
On 5/25/2011 10:02 PM, Juan Pablo wrote: > OS access: > Simultaneous read (4 processes): 118 MByte/s average > Samba local access: > Simultaneous read (4 processes): 102 MByte/s average > Samba server from Windows 7: > Simultaneous read (4 terminals): 70 MByte/s average The first two results above demonstrate a slow disk subsystem not suitable for streaming multiple files to multiple concurrent clients at high data rates. Your spindles are too slow and/or you don't have enough to satisfy your test methodology. Four concurrent dd copies yields 118 MB/s per process, only ~15% disk headroom above wire speed GbE. Your smbd+smbclient local process disk bandwidth overhead appears to be roughly 13 percent. I don't know what the optimal percent here should be but 13% above a dd copy process seems reasonable given the additional data movement through smbd and smbclient buffers. It is clear that you don't have enough head seek performance for 4 or more client streams of 1000 x 8MB files. This doesn't necessarily address the 30% drop in over the wire to Win7 client performance, but we'll get to that later. To confirm the disk deficiency issue, I recommend the following test: Make a 2GB tmpfs ramdisk on the server and run your tests against it, albeit with 200 instead of 1000 8MB files. Instructions: http://prefetch.net/blog/index.php/2006/11/30/creating-a-ramdisk-with-linux/ This will tell you if your server block storage subsystem is part of the problem, and will give you a maximum throughput per Samba process baseline. You should get something like 5GB/s+ local smbclient throughput from a tmpfs ramdisk on that Xeon platform with its raw 25GB/s memory bandwidth. Run a single Win7 workstation SMB test copy to a freshly booted machine so most of the memory is free for buffering the inbound files. This will mostly eliminate the slow local disk as a bottleneck. Now run your 4 concurrent Win7 client test and compare to the single client test results. This should tell you if you have a bonding problem or not, either in the server NICs or the switch. You didn't mention jumbo frames. Enable jumbo if not already. It may help. Something else to consider is that the kernel shipped with CentOS 5.6, 2.6.18, the "Pirate" kernel, is now 4.5 years old, released in Sept of 2006 (http://kerneltrap.org/node/7144). There have been just a few performance enhancements between 2.6.18 and 3.0, specifically to the network stack. ;) The CentOS packages are older than dirt as well. If you're not wed to CentOS you should look at more recent distros. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba for z/OS 1.10
Jim McDonough put forth on 11/15/2010 5:13 PM: > On Sat, Nov 13, 2010 at 6:04 PM, Volker Lendecke > wrote: >> On Wed, Nov 10, 2010 at 02:54:48PM +0100, martin.h...@helvetia.ch wrote: >>> is there any samba version available for download, >>> which runs on IBM MVS, i.e. IBM z/OS 1.10 ...? >> >> There used to be somthing that claimed to run on MVS ages >> (and I mean AGES, my rough guess would be 10 years) ago. > Yep, right around 10 years ago. IIRC it was possible to build on > OpenEdition MVS. That was the last time I touched it. IBM used to > have an SMB server in zOS, though, so it wasn't a real priority. I > have no idea if that is still available. Forgive me for possibly being naive, but why not just run a Linux+Samba VM on top? Wasn't the renaming to "Z series" and "Z/OS" part of IBM's big virtualized Linux on mainframe push? Lemme guess, you'd have to spend a bunch of additional $$ on software, maybe even hardware, just to get a Linux VM up and running? If so, that's a shame. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] samba over internet slow with images/thumbnails
JP CR put forth on 11/10/2010 11:42 PM: > > Hello, > > Iam providing access to many images on a share to windows users from my linux > samba over the internet. The problem is that I need thumbnail viewing because > of the nature of this library and thumbnails take to much time to load it > seems as though it is actually loading the entire image to then display the > small thumbnail. Is this true? Probably yes, especially if there is not thumbs.db file. The remote Windows client, when in thumbnail view in Explorer, will download the entire image and create the thumbnail. In a directory with hundreds or thousands of image files, this will take a long time, possibly hours, over a 1Mb/s broadband connection, for a directory with say 5000 image files. > Also isnt there some kind of caching that can be activated? The caching would have to take place on the client side. AFAIK Explorer performs no file caching. Any web browser will, unless it's been disabled. > Anything to increase this speed. Each image weights about 800kb, and the user > is sitting on a 1mbit line but it takes several seconds for each image. It should take about 6.4 seconds to load each file, assuming no overhead. You will have overhead, so you're looking at 6.4 to 10 or more seconds per file. How many files are in this directory? > Simply not the best experience. Well of course not. You're using the wrong tool for the job. You should be hosting/serving up these files via http. I find lighttpd + curator is a good combination for serving lots of static image files. It works great, as long as the filenames have no spaces in them. Other special characters seem to work fine. If you use this method, and the contents of the image directory change frequently, simply cron curator to run on that directory each night. Using lighttpd (or any web server) and curator, you can achieve something like this: http://www.hardwarefreak.com/construction/ This image page is served from a 500 Kbit/s upstream channel ADSL line. This should give you an idea of the performance you might expect. Click on each thumbnail image to see the full size image. Click on the links in the top right corner to see alternative views and sorting of the thumbnails by file name. You can also click the left and right arrows for a manual slide show, or simply click the top left/right corner of each full size image. To do all of this, simply install curator and the dependencies, cd into the image directory, and type "curator ./". It's that simple. This command created everything you see at the link above. Your *nix distribution may or may not have a curator package. If not, try here: http://curator.sourceforge.net/local/ Also note curator does not work well, if at all, with GIF files. JPGs work great. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] performance transfer (samba VS ftp)
Volker Lendecke put forth on 9/18/2010 12:44 AM: > On Sat, Sep 18, 2010 at 12:22:53AM -0500, Stan Hoeppner wrote: >> Pol Hallen put forth on 9/15/2010 9:36 AM: >> >>> debian stable (samba version 2:3.2.5-4lenny9) >>> >>> from clients by ftp the transfer of huge file is about 10/11Mb/s (with an >>> ethernet 10/100) >>> >>> by samba came 5/6Mb/s >>> >>> is it correct? >> >> Good luck. It appears that tuning smbd and clients, both Windows and >> smbclient, to get anywhere close to wire speed is somewhat of a black >> art. I asked the same question many months ago, and dropped the subject >> after Jeremy said it had to be a problem with the W2K redirector. Funny >> thing is, that same W2K redirector can pull at almost wire speed from a >> WinXP box. The most I've ever been able to get out of smbd is ~8MB/s. >> I'm running 3.2.5-4lenny12. To get anything better than that I'll have >> to go to GigE. I probably won't get anywhere close to wire speed, but I >> should get at least 30-40MB/s, which is 4-5 times what I get now, and >> would thus be a huge improvement for relatively little cost--a few NICs >> and a decent desktop GigE switch can be had for around $100 USD. Even >> without using jumbo frames this would be a huge improvement over 100FDX. > > As always: What about get/put of large files with smbclient, >= 3.2? Hi Volker. I don't have a Linux client machine to test smbclient against my Debian/Samba server. However, running smbclient (3.2.5) on the server and connecting to shares on a WinXP machine and W2K Pro machine hits 11 MB/s (near wire speed of 12.5) all day long with GETing moderate to large files (30MB+). PUTing the same files maxes out at ~6MB/s--very lopsided. I've tried various smbclient -O socket options with no effect on PUT performance. Copying from an smbd share to the Windows machines maxes at 9MB/s. Copying from the Windows machines to an smbd share yields 8MB/s--much more consistent than smbclient. It sure would be nice to have smbclient's 11MB/s GET speed in both directions with all OSes involved. I've tried every option and optimization in smb.conf and the registries of both Windows machines and can't get over 9MB/s. It's sure better than the 5MB/s come people report, so I'm not complaining. It's kinda academic anyway, because the bulk of our transfers to/from smbd are large quantities of small files (< 1MB). Such transfers can crawl at less than 1MB/s. Like I said, I think the best solution for me would be to move to GigE. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] performance transfer (samba VS ftp)
Pol Hallen put forth on 9/15/2010 9:36 AM: > debian stable (samba version 2:3.2.5-4lenny9) > > from clients by ftp the transfer of huge file is about 10/11Mb/s (with an > ethernet 10/100) > > by samba came 5/6Mb/s > > is it correct? Good luck. It appears that tuning smbd and clients, both Windows and smbclient, to get anywhere close to wire speed is somewhat of a black art. I asked the same question many months ago, and dropped the subject after Jeremy said it had to be a problem with the W2K redirector. Funny thing is, that same W2K redirector can pull at almost wire speed from a WinXP box. The most I've ever been able to get out of smbd is ~8MB/s. I'm running 3.2.5-4lenny12. To get anything better than that I'll have to go to GigE. I probably won't get anywhere close to wire speed, but I should get at least 30-40MB/s, which is 4-5 times what I get now, and would thus be a huge improvement for relatively little cost--a few NICs and a decent desktop GigE switch can be had for around $100 USD. Even without using jumbo frames this would be a huge improvement over 100FDX. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] smbcquotas tells me that "quotas are not enabled"
Luke Hamilton put forth on 7/9/2010 3:05 PM: > I think you're right in that quotas aren't enabled on the NAS itself and > there > doesn't appear to be any way of doing so. If I'm to do this, I may have to > invent some way of enforcing quotas for the remote machine at the client. > > But before I get elbow deep in Perl code, I want to try putting a quota on > one > of the Samba shares. Is that possible? I wish I had an answer for you. I just don't have enough experience with quotas. You may just have to experiment with it unless/until someone else posts a solution. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] One account can access samba, another can't.
To be clear, all of my references to UNIX user account pertain to the user accounts on the Samba server host, not Gentoo accounts on the client PCs. Stan Hoeppner put forth on 7/8/2010 9:07 PM: > Michael Sullivan put forth on 7/8/2010 2:41 PM: > >> [homes] >> path=/samba/michael >> valid users=michael >> writable=yes >> >> path=/samba/amy >> valid users=amy >> writeable=yes > > I'd suggest you set the UNIX HOME variable to match these non standard home > paths. For instance, the default UNIX home dir is set as, in my case: > > [08:57:34][s...@greer]~$ set > .. > HOME=/home/stan > .. > > In your case, set the HOME variable for each UNIX user account according to > the correct but non standard path you are using: > > HOME=/samba/michael > HOME=/samba/amy > > Read your distro documentation on how to set the user HOME variable. After > you've done so, you should be able to use something like this in smb.conf: > > [homes] >comment = Home Directories >browseable = no >read only = no >create mask = 0775 >directory mask = 0775 >valid users = %S > > with success. > > There are probably other ways to skin this cat, but this is the setup I've > been using and it works perfectly, albeit on Debian Lenny with Samba 3.2.5 > (workgroup--not a domain controller). Once you've done this you can browse > Windows Network Neighborhood and map the user home share to a drive letter. > -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] One account can access samba, another can't.
Michael Sullivan put forth on 7/8/2010 2:41 PM: > [homes] > path=/samba/michael > valid users=michael > writable=yes > > path=/samba/amy > valid users=amy > writeable=yes I'd suggest you set the UNIX HOME variable to match these non standard home paths. For instance, the default UNIX home dir is set as, in my case: [08:57:34][s...@greer]~$ set .. HOME=/home/stan .. In your case, set the HOME variable for each UNIX user account according to the correct but non standard path you are using: HOME=/samba/michael HOME=/samba/amy Read your distro documentation on how to set the user HOME variable. After you've done so, you should be able to use something like this in smb.conf: [homes] comment = Home Directories browseable = no read only = no create mask = 0775 directory mask = 0775 valid users = %S with success. There are probably other ways to skin this cat, but this is the setup I've been using and it works perfectly, albeit on Debian Lenny with Samba 3.2.5 (workgroup--not a domain controller). Once you've done this you can browse Windows Network Neighborhood and map the user home share to a drive letter. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] smbcquotas tells me that "quotas are not enabled"
Luke Hamilton put forth on 7/8/2010 7:31 PM: > I have a setup of Ubuntu 8.04 running Samba 3.0.28a. Connected to our > network I > have a buffalo linkstation acting as Network Attached Storage (NAS), which I > have successfully mounted on the local file system. > > Using smbcquotas I believe I can set up a quota for each user on the NAS. To > get started, I run the command: > smbcquotas //192.168.1.4/share -S FSQFLAGS:QUOTA_ENABLED -A /etc/.credentials Is 192.168.1.4 the Buffalo NAS? If so... > But I get the error: > Quotas are not enabled on this share. > Failed to open \$Extend\$Quota:$Q:$INDEX_ALLOCATION NT_STATUS_ACCESS_DENIED. Does the Buffalo support NTFS5 and is quota capability enabled on the Buffalo SMB server? > I'm trying to figure out why my command fails. Shouldn't that enable quotas > in > the first place? Not if the Buffalo NAS isn't already configured to support quotas. As I understand it, this command sends a packet to a remote SMB server telling it how to (re)configure quotas on a given share. If quota capability isn't already enabled on the remote SMB server this command will fail. I think that is what is happening here. I'm no expert on this, just making a somewhat educated guess. See: man smbcquotas -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] preferred file system
Moray Henderson (ICT) put forth on 6/29/2010 3:54 AM: > Chris Smith wrote: >> Is there a preferred file system (ext4, xfs, reiserfs, etc.) for >> hosting Samba shares used by Windows clients? What do the devs use? > > I don't know about Samba preferences, but in the current Fedora/RedHat world, > reiserfs does not appear to be a preferred filesystem: there's a thread on > the Anaconda list at the moment discussing removing the reiserfs code from > the installer. Given the myriad of negative issues surrounding Hans Reiser, ReiserFS and successors, it's not surprising that vendors, devs, and end users have been fleeing in droves to other filesystems. I personally use XFS on Debian Stable but with far more current self rolled kernels using kernel.org source. XFS sees constant consistent development, its dev community being very active. Patches seem to be submitted almost daily. It includes a sizable set of management tools including an online filesystem defragger. I've been very pleased with it. There aren't a lot of filesystem benchmark results published for any of the Linux filesystems, but of those I've read, XFS proves to have the best mix of all around performance. I suggest you post your question to x...@oss.sgi.com. You can post without being a subscriber, but if you do, make that clear so people reply to you as well as the list. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Possible Issue with Samba Blocking I/O and CPU
Andy Liebman put forth on 6/10/2010 9:21 AM: > Presumably, with this setting, Samba will only > write out in 256K blocks (which happens to be the stripe size on our RAIDS) Jeremy Allison put forth on 6/10/2010 12:09 PM: > "almost never hit the disk" is on a per-client basis :-). > If a client were mainly reading/writing within a local > area in a file, that fits within the 256m cache, then it > will be served mainly out of that cache. According to Jeremy, using "write cache size = 262144", you end up with a 256 _megabyte_ cache for _each_ smbd process. Apparently the setting value is in kilobytes, not bytes. With 10 active users that equals ~2.5GB of system (virtual) memory allocated to smbd read/write cache. This would definitely explain why you're masking any underlying kernel I/O problem. As Jeremy said, with this configuration, you're now rarely touching the disks. This obviously has nothing to do with matching your RAID stripe width. You've apparently unknowingly thrown so much memory buffer at the problem it is effectively masked. You can test this by dropping from 262144 to 256, lowering the per smbd cache from 256MB to 256KB (which will then equal your stripe width), and your problem will likely resurface. Until you solve the kernel issue, and if memory consumption is now an issue, you may want to play with "write cache size =" values starting at 1024 (1MB) and increasing it 1 or 2MB at a time until the problem is masked again. Gut instinct tells me you shouldn't need a whole 256MB of cache per smbd process to mask the problem. You may find that 16MB or less per process will do the trick. Season to taste. Please keep us updated. These kinds of problems fascinate me, maybe others as well. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] multi-homed samba PDC and NetApp filers
Carl G. Riches put forth on 5/14/2010 7:14 PM: > We are having a problem getting a NetApp filer to re-join a samba > domain after a move to a new network. The filer worked fine with > samba before the move. Apologies in advance for the long missive. I don't know about others here, but it sure would help me understand what the actual problem is if you would define, in detail, what you mean when you say: "a move to a new network" Does this mean: 1. A new building or wing with different switches/routers/cabling 2. A move to a different city/state/country 3. A new Windows Domain 4. A new TCP/IP network class (i.e. from C to A) Troubleshooting anything successfully is identifying what has changed between a working state and a failed state. Identify what things have changed and you should be one giant leap closer to a solution. At the very least that information will allow "me" to help you, and probably other on this list. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] AD Integration drives me nuts
Mike put forth on 5/5/2010 4:20 PM: > Hi Stan > > Knew that... I have all of them pulling the same ntp source. Clock skew > is > 3 secs! :) That's great to hear. For sooo long, too long, this guest clock issue seemed to be "swept under the rug" by VMWare. It's good to know that word if finally out and that people are taking action. If I may point out, you still should look into setting up the guests the "proper" way. Running an NTP daemon or cron'd ntpdate on each guest is frowned upon. That pdf may touch on the reasons why. I haven't actually read that one, but the predecessor doc from 2006. It's best to get the guest kernel setup right to work with a virtualized hw clock and run vmware tools in the guest to keep the guest clock in sync. You run ntpd on the ESX host itself, and that keeps all guest clocks in sync after the guest has been setup properly with vmware tools. I wish I still had a copy of it to give you. I wrote a lengthy and thorough VMWare time sync document for my employer back in 2006 (ESX 2.5 days) due to the massive clock problems we were experiencing. Our entire server environment was hosted on ESX including our Windows AD infrastructure, MSSQL servers, and many Linux guests running iFolder server, Novel Zen server, a few LAMP servers, etc. Getting time sync setup properly solved about 50 different ongoing problems overnight. As you can imagine, I'm a big proponent of getting VMWare time sync setup properly. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] AD Integration drives me nuts
Mike put forth on 5/5/2010 1:38 PM: > Hi > > This has keeping me up for days now and I can't seem to find a solution > in the various wikis, howtos and whatsoevers, so here's the plot: > > I have a W2K3 R2 x64 Domaincontroller (VM on vSphere4) and a CentOS 5.4 > x64 fileserver (also a VM on vSphere4, same ESX-host), running Samba > 3.0.33-3.15.el5_4.1 (rpm installation out of the box). Make sure your system time is accurate on your VM guests. Virtual machines on VMWare ESX are notorious for not keeping time correctly, sometimes drifting by hours in a single day. Read, thoroughly, and implement the recommendations in this guide: http://www.vmware.com/pdf/vmware_timekeeping.pdf Kerberos requires client and server clocks to be no more than 5 minutes apart. From: http://web.mit.edu/Kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Clock-Skew.html "6.2 Clock Skew In order to prevent intruders from resetting their system clocks in order to continue to use expired tickets, Kerberos V5 is set up to reject ticket requests from any host whose clock is not within the specified maximum clock skew of the KDC (as specified in the kdc.conf file). Similarly, hosts are configured to reject responses from any KDC whose clock is not within the specified maximum clock skew of the host (as specified in the krb5.conf file). The default value for maximum clock skew is 300 seconds, or five minutes. MIT suggests that you add a line to client machines' /etc/rc files to synchronize the machine's clock to your KDC at boot time. On UNIX hosts, assuming you had a kdc called kerberos in your realm, this would be: gettime -s kerberos If the host is not likely to be rebooted frequently, you may also want to set up a cron job that adjusts the time on a regular basis." Clock may not be the cause of your current problems, but over 80% of the time it is the cause of kerberos problems with VMWare guests. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Updrading samba
maul...@email.com put forth on 4/29/2010 5:38 AM: > Hello all, > I use samba 2.0.5 in one of my machine and in other machine i use windows xp. > This combination works perfectly when come into file sharing. But when i use > windows vista with samba 2.0.5 i cannot use samba share. I did lots things in > vista to run samba share but iot was helpless. So i like to know that if i > upgrade samba to version 3 or later will i be able to run samba share with > vista and if yes how can i upgrade samba without loosing previous settings. > Please help me out with this. From: http://www.linux-watch.com/news/NS4434907782.html "Fortunately, there are two ways to fix this problem. The first is just to force Vista to use the NTLM protocol as well as NTLM2. To do that, use these commands: Click "Start -> Run." Then, type in the Run field: "secpol.msc." That will bring you to Vista's security policy system. Once there, use "Go to: Local Policies > Security Options" and then find "Network Security: LAN Manager" authentication level. Once there, change the Setting from "Send NTLMv2 response only" to "Send LM & NTLM -- use NTLMv2 session security if negotiated." Ta-da! My Vista workstation could use my Seagate drives. The better long-term solution is to upgrade any of your Samba servers to 3.0.22 or higher, since they can handle NTLMv2. 3.0.21 will also do the trick, but it has a security hole in it, so if you're still using it, upgrade as soon as possible. The most recent stable version of Samba is 3.0.23d, and I highly recommend it." Upgrading to Samba 3.0: http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/upgrading-to-3.0.html -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] [oOT] ploenk....@eplus.blackberry.com please fix your mail forwarding
I've received a bunch of these blackberry backscatter messages over the past week and have been unable to determine which list user is the cause of this. Whoever is forwarding your email to the blackberry address below, please fix the situation. It's becoming really annoying receiving these backscatter bounces that give no clue as to what the nature of the problem is. Thanks. Your message: To: ploenk@eplus.blackberry.com Subject: Re: [Samba] Ideas for distributed Samba servers Sent Date: 47:37 + has not been delivered to the recipient's BlackBerry Handheld. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba - Swat
Lucy Little put forth on 4/16/2010 7:54 AM: > My husband has installed Samba - swat and wants to link all the computers in > the house, so "he can back them up daily." > I read the About info on your website, but still have a few questions: > > 1. I work online, can Samba capture any information (passwords, screen shots, > personal information, administrative log on) that might jeopardize my job's > security? > 2. Can personal emails be tracked and passwords captured? > 3. Can live chat be captured? > 4. Can personal email addresses be opened using Samba? If your trust level of your husband is that low, I'd say it's time for a new husband. Samba doesn't do any "data capturing". The only thing you need to worry about is "stored" passwords and data. If he sets this up so your entire local hard disk is copied to the Samba server, then the server will have a copy of everything on your hard drive. This is a smart thing to do actually, having complete backups. Again, if you trust your husband there is no issue with this backup method. If you don't trust your husband, trade him in for husband 2.0 (or 3.0 or whatever the case may be), *or* just don't allow him access to your PC. Period. Again, the far far greater issue here is your level of trust in your husband, not what any piece of technology or software would enable him to do in the spying arena. Hope this advice helps. Good luck Lucy Little. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] WG: Upgrading 3.2.15 to 3.3.12 sernet package on opensuse 10.2
Daniel Müller put forth on 4/14/2010 9:27 AM: > EXT oid=1.3.6.1.4.1.1466.20037 > Apr 8 09:22:20 tuepdc slapd[7693]: do_extended: unsupported operation > "1.3.6.1.4.1.1466.20037" > Apr 8 09:22:20 tuepdc slapd[7693]: conn=441 op=0 RESULT tag=120 err=2 > text=unsupported extended operation This is an OpenLDAP problem, not a Samba problem. I have zero experience with LDAP but I know how to Google and read. Please paste all the relevant log entries from the PDC. There should be a few more than what you pasted, such as these posted back in July 2008 to another help forum: Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 fd=23 ACCEPT from IP=127.0.0.1:15332 (IP=0.0.0.0:389) Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 op=0 do_extended: unsupported operation "1.3.6.1.4.1.1466.20037" Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 op=0 RESULT tag=120 err=2 text=unsupported extended operation Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 op=1 UNBIND Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 fd=23 closed Jul 9 07:32:26 xdaolin slapd[2241]: conn=703 fd=23 ACCEPT from IP=127.0.0.1:15333 (IP=0.0.0.0:389) Jul 9 07:32:26 xdaolin slapd[2241]: conn=703 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 9 07:32:26 xdaolin slapd[2241]: conn=703 op=0 do_extended: unsupported operation "1.3.6.1.4.1.1466.20037" Jul 9 07:32:26 xdaolin slapd[2241]: conn=703 op=0 RESULT tag=120 err=2 text=unsupported extended operation Jul 9 07:32:26 xdaolin slapd[2241]: conn=703 op=1 UNBIND Jul 9 07:32:27 xdaolin slapd[2241]: conn=703 fd=23 closed Jul 9 07:32:27 xdaolin getent: nss_ldap: could not search LDAP server - Server is unavailable Note that "1.3.6.1.4.1.1466.20037" exists in both help requests, and that the other OP is not having problems with Samba but some other application, _two years ago_. I've found examples of the same error going back to 2006. I have yet to find via Google any document with this 1.3.6.1.4.1.1466.20037 error string having anything to do with Samba. Your problem is with your platform/OpenLDAP configuration. Have you upgraded OpenLDAP? Have you upgraded all your libraries to the latest versions? What operating system are you using? What version? Forget the fact that everything "works" on the BDC. That is not a factor here because the machines are NOT identical. One is a PDC, the other a BDC. Just because the BDC works after the Samba upgrade doesn't automatically mean the PDC should work, given that the problem isn't with Samba, but with OpenLDAP. Google for "EXT oid=1.3.6.1.4.1.1466.20037" and read every article in the first 3 pages. That should help you find your answer. Save yourself some time by upgrading all packages and libraries first to see if that fixes the problem, starting with OpenLDAP. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba and mulitple user connections
Miller, Amber put forth on 4/9/2010 9:22 AM: > I have a Solaris system with Samba on it, along with two PC's a windows > 2000 and XP. Shares were setup via SWAT. A user can access the shares > on the 2000 machine after putting in login credentials when browsing > through windows explorer. However, when trying to login the same share > through XP the user gets "network connection has been lost." Although > the XP machine can and stays connected via the SWAT web page. I'm at a > loss...Are there restrictions on multiple connections to a share via the > same username with Samba? Maybe this? "Limiting the number of concurrent connections Samba is able to limit the number of concurrent connections when smbd is launched as a daemon (not from inetd). The 'max smbd processes' smb.conf option allows Administrators to define the maximum number of smbd processes running at any given point in time. Any further attempts from clients to connect to the server will be rejected." max smbd processes = 1 That could cause the problem you describe. Check /etc/samba/smb.conf (or where ever Solaris keeps the file) and make sure "max smbd processes" isn't defined. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Ideas for distributed Samba servers
Robert LeBlanc put forth on 4/11/2010 8:19 PM: > On Sun, Apr 11, 2010 at 9:03 AM, ravi channavajhala < > ravi.channavajh...@dciera.com> wrote: > >> WAFS (Wide Area File System) appliances can be very well deployed for this >> sort of thing precisely. Unfortunately, I don't know of any opensource >> project for WAFS. However, commercial solutions such as Riverbed, Expand >> Networks, CISCO/WAFS, Juniper/Peribit do exist. >> >> > So far, this is the direction that we may go. We have looked at a Riverbed > product, it's good to know alternatives. This may not be as much of an issue > as it was in the past as I believe we my get a network upgrade that will > negate the need for this. I would think it would be cheaper and more straight forward to replace the GbE port on each end of the fiber link with a 10GbE port than to deal with the complexity of caching and replication, or other such options, especially for two buildings on the same campus. The fiber link is on campus and thus you control any right-of-way issues, correct? If this is the case, upgrading the link speed on the fiber is definitely the way to go. If multiple pairs were run when the line was originally trenched, as is customary, setup ISL bonding of two 10GbE links between the two buildings' switches. Problem solved. Make sure you have at least one 10GbE NIC (preferably two NICs bonded) in the Samba server that exports the data on the disk array or the fat pipe between the buildings won't matter much. It will be interesting to see what Samba bottlenecks you run into after you get the big phat pipes setup. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Upgrading 3.2.15 to 3.3.12 sernet package on opensuse 10.2
Daniel Müller put forth on 4/10/2010 2:11 AM: > > > Dear all, I have samba 3.2.15 PDC running with an openldap backend and > smbd4wins on the same host. There is also a BDC the same as my PDC. After I > did an update to 3.3.12 on my BDC this worked on the fly without problems. > Then I went on doing the same update on my PDC with the result of chaos. No > user was able to logon anymore , when I did a smbclient -L mypdc -N it was > extremely slow, and my whole domain was down. After a few hours searching > for the reasons, I only saw an error with the samba talking to my openldap > on my PDC (this error was definitly not on my BDC with quiet the same > configuration) that searching the ldap database. At the end the only way to > solve this was to downgrade again to 3.2.15. Is there a way to upgrade a > samba PDC to 3.3.12 without fail!? Greetings Daniel It might help if you share that error message with the list. Just telling us that you upgraded Samba and something broke doesn't give us much to go on. Error messages, relevant log entries, and config files are always helpful. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] smbd will not start
Hi Bill, Jump on #debian at irc.debian.org or join the debian-user mailing list: http://lists.debian.org/debian-user/ There are tons of Debian folks willing and able to help you get Debian Samba working properly, and many more aptitude/dpkg experts. -- Stan Bill Purcell put forth on 4/9/2010 10:11 AM: > At Fri, 9 Apr 2010 16:52:43 +0200, > Volker Lendecke wrote: >> On Fri, Apr 09, 2010 at 09:25:10AM -0500, Bill Purcell wrote: >>> libwbclient is already installed >> That is the same version that you have just compiled? That >> means, is smbd compiled from the same Samba source tarball >> that the libwbclient that you have installed in your system >> right now? > > I used aptitude to install the package. So it was pre-compiled > before installation on my system. If the version of libwbclient > should match the version of samba and samba-common, then I might have > a problem. > > == > [10:05:44] ~$ dpkg -l | egrep "samba|libwb" > ii libwbclient0 2:3.4.7~dfsg-1 > Samba winbind client library > ii samba 2:3.2.5-4lenny9a > LanManager-like file and printer server for Unix > ii samba-common 2:3.2.5-4lenny9 > Samba common files used by both the server and the client > == > > Should these two version be the same? Is there any easy way with dpkg > or apt to make this happen? If not, I assume I will have to build > from source? Is there a decent tutorial on this, including a list of > dependencies? > > Bill -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] unix exts / wide links / symlinks
Linda W put forth on 4/6/2010 6:44 PM: > As it stands -- with any autodate, or any update, I load from my vendor, > I will find my whole setup failing -- as these links are key to my setup > working. > I'll have to recompile every update the instant it hits -- and if autoupdate > is > turned on -- the first I'll see is no client being able to access their > personal > Documents folder -- which is put in a separate location for various > administrative > reasons. The Debian Linux package manager system allows the OP to "pin" certain packages so they are left alone during updates. IIRC, you can also configure it to notify you when a new version of a pinned package is available, so you can take any necessary action. I.e. if the package update is due to a security issue, you can go ahead manually roll a new copy with your custom patches and install it. If the update isn't a security fix, but a feature update you don't really need, you can ignore the situation until the next security update comes along, saving yourself some of the rebuild episodes. This obviously isn't an optimal solution either as it still requires some manual work. But it's a bit better than the situation you describe. Does your distro's package manager have a package pinning feature? Have you looked for a non-vendor package with the feature you need maintained by a third party? That may be an option as well. Have you checked to see if your Linux vendor maintains a version of the samba package with feature, but it's not made available via the standard channels? If more than a handful of people need a feature, in the Linux world, usually someone is maintaining a copy someone around the globe. None of these possible solutions are perfect, but one or more of them may be a little better than your current situation. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Fwd: Samba SMB throughput
John Drescher put forth on 3/29/2010 9:42 PM: > -- Forwarded message -- > From: John Drescher > Date: Mon, Mar 29, 2010 at 10:42 PM > Subject: Re: [Samba] Samba SMB throughput > To: Stan Hoeppner > > > On Mon, Mar 29, 2010 at 9:59 PM, Stan Hoeppner wrote: >> Mahmud Siddiqi put forth on 3/29/2010 5:40 PM: >>> Hello everyone, >>> >>> Quoting from Samba Team Blog #2 (25 Sept 2009): >>> >>> "Volker showed how to get more than 700MB/sec from Samba using >>> smbclient and a modern Samba server, which shows what you can >>> really do when you understand the protocol thoroughly and don't feel >>> you have to invent a new one (SMB2 :-)." >>> >>> Would it be possible to get a complete accounting of how this was achieved? >> >> First off, that's a misprint, unless this test was done with 10GbE ethernet, >> which I highly doubt. > >>From what I remember it was done with 10GbE Ethernet. In that case a document covering that experiment would be an interesting read. Somebody must have had relatively deep pockets, or donated hardware. Or borrowed time on systems at one of the vendor proving labs. The retail price of the hardware I'm guessing would have been required for this test would have been more than the average IT salary in the midwest, possibly double. Got a link? -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba SMB throughput
Mahmud Siddiqi put forth on 3/29/2010 5:40 PM: > Hello everyone, > > Quoting from Samba Team Blog #2 (25 Sept 2009): > > "Volker showed how to get more than 700MB/sec from Samba using > smbclient and a modern Samba server, which shows what you can > really do when you understand the protocol thoroughly and don't feel > you have to invent a new one (SMB2 :-)." > > Would it be possible to get a complete accounting of how this was achieved? First off, that's a misprint, unless this test was done with 10GbE ethernet, which I highly doubt. The test was likely done with 1 GbE. Thus it should read 700 Mb/s in that quote. Big B is Bytes, small b is bits. Streaming 700 Mb/s, or 700/8 = 87.5 MB/s, with decent GbE cards with TCP offload, such as the Intel GbE NICs, a decent managed GbE switch, along with enough RAM and a relatively fast disk, low end striped array, or SSD, should be fairly easily achievable by most anyone. It may or may not require jumbo frames. I've not tried this myself. If it does require jumbo frames, then the setup wouldn't be all that useful to most people as there is no IEEE 802.x standard for jumbo frames, and networking gear that fully supports jumbo frames tends to be relatively expensive. The tweaks in smbd and smbclient to make best use of the available network bandwidth are relatively trivial. What really counts in this scenario is having decent quality GbE hardware, quality cabling, and enough horsepower in the host on each end to push and digest the TCP stream. Modern Linux kernels auto tune the TCP stack so there's little to do there as well. Once you've got the decent hardware, tuning out the minor software bottlenecks is relatively straightforward. Achieving these results in a mixed Linux, Windows, *BSD, Mac OS network is probably much trickier. Linux-Linux should be relatively easy. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] how to synch multiple servers?
PTaco put forth on 3/26/2010 11:01 AM: > > DRDB is a whole file system correct? http://www.drbd.org/ -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] acl_xattr vs acl_tdb
Volker Lendecke put forth on 3/26/2010 7:39 AM: > On Fri, Mar 26, 2010 at 08:38:19AM -0400, simo wrote: There's something I would really like to know! But somehow it seems to be a secret of the gods that us mere mortals are not allowed to penetrate... >>> >>> Please say if there is any size restriction for xattrs in >>> XFS. Hopefully there is none, which would mean that you can >>> fill the whole file system with a single security descriptor >>> if you wish. >> >> If I remember correctly XFS used to have a size limit of 64KiB per >> xattr. > > Shall I call you god now? :-) No me. Err, wikipedia: XFS provides multiple data streams for files through its implementation of extended attributes. These allow the storage of a number of name/value pairs attached to a file. Names are null-terminated printable character strings of up to 256 bytes in length, while their associated values can contain up to 64 KB of binary data. They are further subdivided into two namespaces, root and user. Extended attributes stored in the root namespace can be modified only by the superuser, while attributes in the user namespace can be modified by any user with permission to write to the file. Extended attributes can be attached to any kind of XFS inode, including symbolic links, device nodes, directories, etc. The attr program can be used to manipulate extended attributes from the command line, and the xfsdump and xfsrestore utilities are aware of them and will back up and restore their contents. Most other backup systems are not aware of extended attributes. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Windows 7 + Samba 3.4.5 locking problem
Lars Bensmann put forth on 3/5/2010 7:12 PM: > Thanks for the hint. I should have thought about this earlier. I did copy > everything to one of the Windows 7 clients, set up a share and everything > works fine. I really don't like this as a permanent solution but at least > it's a (temporary?) workaround and it shows that it is indeed a Samba > problem. You're welcome. This is a great step to take and seems to confirm the problem is indeed with Samba, or at least the version you're running, and will hopefully help in nailing down exactly where the problem lies within Samba. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Windows 7 + Samba 3.4.5 locking problem
Rune Tønnesen put forth on 3/5/2010 3:11 PM: > Den 05-03-2010 20:42, Lars Bensmann skrev: >> Hello, >> >> after having no problem with four Windows 2000 workstations and one Samba >> 2.something server for several years in a medical practice the practice >> software (DocComfort) dropped support for Windows 2000 beginning of this >> year. So I bought new hardware for the workstations and servers and >> installed from scratch. Now there are four Windows 7 Professional 32bit >> Workstations (with UAC disabled) and one Debian Lenny Server with Samba >> from backports.org (I started with 3.4.3 (2:3.4.3-1~bpo50+2) and just now >> upgraded to 3.4.5 (2:3.4.5~dfsg-1~bpo50+2), but this did not make a >> difference). It's 2010. This style of application design is archaic. Any application of this nature in 2010 should be using a network database engine (Oracle, MSSQL, MySQL, DB2, PostgreSQL, etc) instead of shared file locking, especially in the medical field. Is it possible that this new version of DocComfort finally switched to a database server driven design, and they left the shared file access mode as a legacy compatibility mode for those who've not switched to the db model? And they fubar'd the shared file access mode of the latest version in the process? Neglected it? Etc? If no db engine version, then copy everything to a Win7 PC and share it. Configure all the PCs to access that share. If the problem persists, the cause is DocComfort, not Samba. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] How do I mount a share on my Debian server ?
Gungne Gungneson put forth on 2/16/2010 5:53 PM: > Do I have to open ports in my firewall? Tell us more about the scenario when you're outside the firewall. Are you wanting to access SMB/CIFS over the internet from your laptop? Or is this firewall between two segments of a corporate network, say within the same building, or same campus LAN? -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Winbind Offline Login
Johan Meiring put forth on 2/16/2010 10:16 AM: > Because Samba cannot be a DC in an AD domain yet. My bad Johan. I had assumed that Samba could do it with LDAP and AD integration. I've not done it myself, I just assumed the capability was there already. > My other option would be to create a Samba DC with a second domain and a > trust relationship. That's not quite as kludgy, but still less than elegant. > I just hoped that the "winbind offline logon" would allow Samba to serve > shares using cached credentials. I've never had luck with that, but I'm not that familiar with the Samba winbind tweaks. Maybe one of the devs or experienced OPs will have a clue on how to best do this. Best of luck with it. Sorry I wasn't able to be more helpful. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Winbind Offline Login
Johan Meiring put forth on 2/16/2010 9:11 AM: > Hi, > > I have the following setup. > > Office A - Windows 2003 DC > Office B - Samba 3.4.5 domain member > > I want users in Office B to still be able to access files on the Samba > domain member when the link between Office A and Office B does down. > > I have enabled "winbind offline logon". > > If I now break the link between Office A and Office B. All work as > expected. (I did not test longer than 5 minutes, dont know if "winbind > cache time" will come in to play). > > But if a workstation in Office B then logs off, and logs back on, they > cannot access shares on the Samba Domain Member anymore. > > I realise that "winbind offline logon" mentions that it is for local pam > logons to the Samba Server itself. > > Is there any other way to allow cached access to shares on the Samba > server in Office B? This probably requires making the domain member server a DC. Member servers can't authenticate domain users. To accomplish what you want without making this samba server a DC, you'd have to create "local" accounts on the server and have each workstation log into those accounts to get access to the shares. You'd also have to add all these local accounts to the shares. In essence, you'd be creating a standalone samba server atop a domain member server. This is a very kludgy way of going about it. Is there a particular reason you didn't make this server a DC in the first place? Just about every architectural diagram I've ever seen says to place a DC in every satellite office for exactly this reason, so people can still login and access resources when the link to corporate goes down. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Moving PDC from Fedora to RHEL5 - _net_auth2: creds_server_check failed. Rejecting auth request from client
Paul Furness put forth on 2/12/2010 12:34 PM: > It *may* be possible to re-join the domain with the workstation, but I'm > fed up with doing that every time I upgrade... Hi Paul. Not trying to be a jerk or anything, but you didn't *upgrade* in this scenario. You *downgraded* in a big way. Look at the revs on everything below. Every single one dropped far back in the time machine by moving to RHEL. Any distro with "Enterprise" or "Stable" in the name is bound to be quite a bit behind the bleeding edge. The free community distro versions are where the edge development occurs. You were running such an edgy distro and then went "Enterprise". That is never a good idea, and you are learning why in this case. You need to upgrade these packages back up to their previous revs, if you can. If not, put the identical Fedora setup on the new machine. > Version info: > > Working PDC: > Fedora 10, kernel 2.6.27 > Samba 3.2.15, smbldap-tools 0.9.5 > openldap 2.4.12 > > New PDC (not working): > RHEL 5.4, kernel 2.6.18 > Samba 3.0.33, smbldap-tools 0.9.4 > openldap 2.3.43 -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Client link utilization
Bostjan Skufca put forth on 2/8/2010 4:07 PM: > Thanks! > > "We have a bidder at 7,5 MB/s, do I hear more? Do we have 8 MB/s?" :) 8.5MB/s here from both (an old) smbclient and Winders 2K/XP. But, of course, you already knew that from my previous posts. Just getting it into this thread for your tally. I'm hoping I can eventually figure out how to get wire speed out of smbd 3.2.5, or Debian's successor rev. I kinda feel greedy, with you only getting ~4MB/s and me [demanding] 11MB/s. :( -- Stan > On 8 February 2010 21:27, Lennart Sorensen > wrote: >> On Mon, Feb 08, 2010 at 08:53:11PM +0100, Bostjan Skufca wrote: >>> Ok, a quick questions for everyone: >>> >>> Can you max a 100Mbps ethernet connection to SMBD server using >>> smbclient or mount.cifs? >>> >>> What transfer speeds can you reach? 8MB/s, 10MB/s, 11,5MB/s? >>> >>> Thanks everybody, >>> b. >>> >>> PS: Because if you can and I can't, that means only I have a client >>> side problem. >> >> Well using a 100Mbit connection, nfs gives me 11.3MB/s and using cifs >> gives me 7.5MB/s. Same file from same server to the same client using >> rsync --progress to show the transfer rate of receiving from the server. >> >> Samba 3.4.2 on the server. >> >> -- >> Len Sorensen >> -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] Client link utilization
Jeremy Allison put forth on 2/6/2010 11:07 PM: > On Sat, Feb 06, 2010 at 09:26:32PM -0600, Stan Hoeppner wrote: >> Bostjan Skufca put forth on 2/6/2010 6:14 PM: >>> Hello everybody! >>> >>> This is probably going to be a classic question but I cannot find a >>> decent answer on net. >>> >>> I have samba server set up and the following things work flawlessly: >>> - iperf shows 92% link utilization >>> - FTP/SCP/HTTP transfers work in 10MB/s range. >>> >>> However, when I mount samba share with linux client (mount.cifs) the >>> link utilization cannot bypass cca 33%. Transfer speeds constantly >>> stops around 3.8MB/s and will not rise above it no matter what socket >>> and locking options I use. >>> >>> Do you have any ideas about why this is happening and/or FAQ websites >>> to point me to? >> >> I've had a similar thread running for a few weeks without resolution. In my >> case I can max the wire (100FDX) at 92Mb/s to/from Win2K and WinXP clients >> using >> FTP, and smbclient from the server to shares on the workstations maxes the >> wire >> (at least GET from the workstations does). I'm running Samba 3.2.5 on Debian >> Lenny with custom kernel 2.6.31.1. >> >> The max smb performance I can get in a single stream to/from smbd is 65Mb/s, >> or >> 8.5MB/s. I've now tested Win2K, WinXP, and smbclient on SLED 10 (can't >> recall >> version). In all cases, no matter what performance settings I tweak in >> smb.conf >> or on the workstations, I can't get wire speed with a single SMB >> stream---can't >> get over 65Mb/s. >> >> Interestingly, two simultaneous SMB transfer streams (two Windows Explorer >> file >> copy operations on the same workstation) will max the wire at 92Mb/s, or >> 11MB/s. > > Hang on a minute, I haven't been paying attention to these emails > as yet. Thanks for jumping in Jeremy. > Am I correct in saying: Partially. Before I forget, let me state I'm only speaking for my case, not the other OP with a similar issue, whose thread this is. > smbclient -> smbd maxes the wire. This is not correct. SLED 10's smbclient (2006'ish, not sure of version) gets 2/3 wire speed to/from the smbd server, Debian Lenny Samba 3.2.5. In this case, it's seeing exactly the same single stream performance as the Windows clients. > smbclient -> WinXP maxes the wire. Yes, smbclient 3.2.5 on the Debian Lenny smbd server can GET from WinXP and Win2K at wire speed, however, PUT ops are half wire speed, 6MB/s. I haven't attempted to troubleshoot this half speed issue yet. > But WinXP -> smbd gets 2/3 of the wire speed. Correct. Win2K and WinXP both achieve 2/3 wire speed to/from smbd. > And WinXP+WinXP (two streams) -> smbd maxes the wire. Correct, but mostly tested from a Win2K machine, not XP. Just to be clear, this is two streams from one Windows host. Two concurrent file copy ops from two shares on the smbd server, and this maxes the wire every time. > If this is the case, it's the 64k per read/write > limit plus only one outstanding packet per stream > issue with the WinXP redirector that's the issue. Hmm. If this is the case, why do the Win hosts nearly max the wire talking smb to one another, at ~10.5MB/s, and max the wire serving files to smbclient on the Linux server host? > smbclient sends up to maxmux outstanding packets > on read/write and keeps the pipeline full. That's > why it can max the wire. Well, smbclient 3.2.5 maxes the wire GETing from the Windows hots' shares, but only hits 1/2 wire speed on PUT ops to the Windows shares. SLED 10 smbclient only reaches 2/3 wire speed <-> smbd on the Debian Samba server, although I didn't test SLED 10 smbclient against the Windows hosts. > The WinXP redirector is just not very good I'm > afraid. That may be true. But I'd be remiss if I didn't point out that XP is one of two machines I have which can actually serve single stream smb at wire speed. The other, sadly, is Win2K. Both can serve smb to smbclient running on the Debian smbd server at wire speed, and just a shade under wire speed to one another. The only piece of smb software I have in my normal environment that hasn't demonstrated single stream wire speed capability is, sadly, smbd. Thanks for taking interest Jeremy. Hopefully you can point me in the right direction so I can figure this out. It's probably something simple or stupid, but hidden or obscure. I'm running a custom kernel, so I guess it's possible I screwed something up in my kernel config. I've got netfilter in the kernel but no current iptables rules configured. I just don't know where to look next. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Client link utilization
Bostjan Skufca put forth on 2/6/2010 6:14 PM: > Hello everybody! > > This is probably going to be a classic question but I cannot find a > decent answer on net. > > I have samba server set up and the following things work flawlessly: > - iperf shows 92% link utilization > - FTP/SCP/HTTP transfers work in 10MB/s range. > > However, when I mount samba share with linux client (mount.cifs) the > link utilization cannot bypass cca 33%. Transfer speeds constantly > stops around 3.8MB/s and will not rise above it no matter what socket > and locking options I use. > > Do you have any ideas about why this is happening and/or FAQ websites > to point me to? I've had a similar thread running for a few weeks without resolution. In my case I can max the wire (100FDX) at 92Mb/s to/from Win2K and WinXP clients using FTP, and smbclient from the server to shares on the workstations maxes the wire (at least GET from the workstations does). I'm running Samba 3.2.5 on Debian Lenny with custom kernel 2.6.31.1. The max smb performance I can get in a single stream to/from smbd is 65Mb/s, or 8.5MB/s. I've now tested Win2K, WinXP, and smbclient on SLED 10 (can't recall version). In all cases, no matter what performance settings I tweak in smb.conf or on the workstations, I can't get wire speed with a single SMB stream---can't get over 65Mb/s. Interestingly, two simultaneous SMB transfer streams (two Windows Explorer file copy operations on the same workstation) will max the wire at 92Mb/s, or 11MB/s. Our symptoms are similar, though we may be fighting different causes, given you can't even get over 4MB/s. I've provided multiple packet captures as instructed, but haven't heard anything back yet. That was over a week ago... -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] (no subject)
James Hurlburt put forth on 2/2/2010 4:56 PM: > NET805: NETWORK DEVICE NO LONGER EXISTS READING DRIVE U > > Abort, Retry, Fail? Hi James, You didn't happen to put the new Samba server on a different IP subnet or VLAN than the old server did you? You didn't show the IP's and subnet masks of each machine. IIRC, NETBIOS can have problems crossing some routers and VLANs, possibly other network boundaries. If you aren't already, the first thing I'd do is get the new server on an IP address consecutive to the old server and make sure they're jacked into the same switch. This should eliminate any possible network topology issues causing problems. Is the new server a virtual machine? Make sure the hypervisor is allowing NETBIOS traffic to flow from the physical NIC to/from the VM. Actually, I should say, make sure it isn't disallowing such traffic. This is unlikely, but it's best to check. Running in a VM can often cause goofy hard to solve problems because of things not working at low levels the way we expect them to. Lastly, disable any iptables rules on the new server or other firewall scripting software, and disable SELinux if it is enabled. Look at netstat -an on both servers when connecting with the clients, and make sure all the same ports are being used. That's about all I can think of at this point. As Gunter mentioned, a network trace couldn't hurt. I'd probably try a few of the less time consuming recommendations above before resorting to the trace. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)
Stan Hoeppner put forth on 1/27/2010 4:37 PM: > Stan Hoeppner put forth on 1/25/2010 5:30 PM: >> Volker Lendecke put forth on 1/25/2010 1:28 AM: > >>> The dual-stream one is kindof limited help. The interesting >>> piece is how Win->Win does its thing faster, so we need to >>> see that one. >> >> I've been busting my but trying to get you something meaningful. This dump >> is >> less than optimal for two reasons, but it's the best I can get you thus far. >> >> 1. Running tshark on Win2K creates a huge network performance hit and thus >> b/w >> numbers for small file (<250MB) transfers don't come close to accurately >> describing the real world. With tshark running the b/w is less than half of >> normal with small files. >> >> 2. Because of this I had to do a huge file copy to allow time for the >> client to >> level off at peak performance, which is still ~500KB/s lower than normal due >> to >> tshark overhead. >> >> Anyway, the file is over 400MB. It'll take quite a while to grab off my >> server. >> >> http://www.hardwarefreak.com/smb-winwin-single-stream >> >> Hope you are able to glean something meaningful from it. > > Were you able to grab this trace file yet Volker? If so, have you found > anything interesting yet when comparing it to the previous Samba->Win2K trace > file? Any clues yet as to why the win-win throughput is almost 3MB/s better > than Samba->Win? If you haven't dug into it yet, as a reminder, this last > trace > capture was done with tshark on windows. The previous trace file was captured > on the Linux machine with tcpdump. Some additional data points to add to this performance issue. Using smbclient 3.2.5 on the samba server box, with no tweak options, I ran get/put tests to each of the Windows workstations. The results are interesting to say the least. The get performance maxes the fast ethernet link at ~11MB/s. If you recall, the workstations max out their upload to smbd at ~8MB/s, with the same for download. If smbclient on the smbd box can pull from a workstation at 11MB/s, using the same TCP/IP stack and SO settings smbd should be able to absorb an upload at 11MB/s because it's the same path. But it doesn't, it caps the workstation uploads (and downloads) at ~8MB/s, no matter what options I try. Windows XP Home machine: smb: \> get src.exe getting file \src.exe of size 121983488 as src.exe (11276.5 kb/s) (average 11276.5 kb/s) smb: \> put src.exe putting file src.exe as \src.exe (6149.3 kb/s) (average 6149.3 kb/s) Windows 2000 Pro machine: smb: \> get src.exe getting file \src.exe of size 121983488 as src.exe (11195.9 kb/s) (average 11195.9 kb/s) smb: \> put src.exe putting file src.exe as \src.exe (6362.5 kb/s) (average 6362.5 kb/s) -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] DOS dir command on Samba share
Stan Hoeppner put forth on 2/1/2010 10:48 PM: > Braxton Neate put forth on 2/1/2010 9:37 PM: >> Hi, >> >> I was wondering if anyone could shed some light on a problem I am having >> with the DOS DIR command on a SMB share. >> >> I have a batch script that copies files from one mapped network drive to >> another. To check that the copy has been sucsessful it creates two text >> files with the output of the command "dir /s | find "File"" on >> both directories. >> >> We have recently upgraded one of the servers from Windows to Samba running >> on RHEL 5. For some reason now the output of the dir command comes in a >> different order and the total byte size is different on the samba share than >> the native Windows share thus breaking the check. All the file appear to by >> copied correctly though. >> >> I have attached a sample of what happens. >> Any help is greatly appreciated. > > You should be able to fix the directory order issue by setting the environment > variable > > set dircmd=/ogn > > on the Windows machine running the script. The file size discrepancy probably > has to do with the fact that you changed the underlying filesystem from (I > assume) NTFS to one of EXT2/3/4, ReiserFS, XFS, or JFS. Each filesystem may > report slightly different sizes for files and directories. This problem may > be > more difficult to solve. Are you currently using? > > fstype = NTFS or > fstype = Samba > > You may try swapping those and see if it fixes the file size issue. I have no > idea if this will help, but you might try it. However, keep in mind that any > software that attempts to store information in NTFS alternate data streams > will > be unable to do so. For example, the Windows 2000 file viewer, Windows > Explorer, stores image file thumbnail data in ADS on NTFS filesystems. Thus, > if > you enable fstype = NTFS and the underlying FS is say, ext3 or XFS, thumbnail > data will not be written to the AFS as it doesn't exist, and on top of that, > Explorer will not automatically fall back and create a thumbs.db file, which > is > how thumbnail data is handled on FAT32 and all filesystems *other than* NTFS. > Thus, if one has thumbnail view enabled on a Samba share containing hundreds > or > thousands of photos, the thumbnail data must be regenerated, for every file, > each time the share is viewed, and this is _painfully_ slow. I took me more a > few hours to figure this out. > > So, again, exporting a *nix Samba share as NTFS will cause unforeseen problems > with applications that expect the AFS to exist on the filesystem. > > It seems your current verification method may not work in the future. Have > you > looked into a fully automated, purpose built tool for this task, such as > rsync? > It may give you some more options and flexibility to accomplish your goals. > > http://samba.anu.edu.au/rsync/ Come to think of it, these file size differences being reported may be directly related to existing alternate data streams on your NTFS volume. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] DOS dir command on Samba share
Braxton Neate put forth on 2/1/2010 9:37 PM: > Hi, > > I was wondering if anyone could shed some light on a problem I am having with > the DOS DIR command on a SMB share. > > I have a batch script that copies files from one mapped network drive to > another. To check that the copy has been sucsessful it creates two text files > with the output of the command "dir /s | find "File"" on both > directories. > > We have recently upgraded one of the servers from Windows to Samba running on > RHEL 5. For some reason now the output of the dir command comes in a > different order and the total byte size is different on the samba share than > the native Windows share thus breaking the check. All the file appear to by > copied correctly though. > > I have attached a sample of what happens. > Any help is greatly appreciated. You should be able to fix the directory order issue by setting the environment variable set dircmd=/ogn on the Windows machine running the script. The file size discrepancy probably has to do with the fact that you changed the underlying filesystem from (I assume) NTFS to one of EXT2/3/4, ReiserFS, XFS, or JFS. Each filesystem may report slightly different sizes for files and directories. This problem may be more difficult to solve. Are you currently using? fstype = NTFS or fstype = Samba You may try swapping those and see if it fixes the file size issue. I have no idea if this will help, but you might try it. However, keep in mind that any software that attempts to store information in NTFS alternate data streams will be unable to do so. For example, the Windows 2000 file viewer, Windows Explorer, stores image file thumbnail data in ADS on NTFS filesystems. Thus, if you enable fstype = NTFS and the underlying FS is say, ext3 or XFS, thumbnail data will not be written to the AFS as it doesn't exist, and on top of that, Explorer will not automatically fall back and create a thumbs.db file, which is how thumbnail data is handled on FAT32 and all filesystems *other than* NTFS. Thus, if one has thumbnail view enabled on a Samba share containing hundreds or thousands of photos, the thumbnail data must be regenerated, for every file, each time the share is viewed, and this is _painfully_ slow. I took me more a few hours to figure this out. So, again, exporting a *nix Samba share as NTFS will cause unforeseen problems with applications that expect the AFS to exist on the filesystem. It seems your current verification method may not work in the future. Have you looked into a fully automated, purpose built tool for this task, such as rsync? It may give you some more options and flexibility to accomplish your goals. http://samba.anu.edu.au/rsync/ -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] flushing sambacache
Learner Study put forth on 1/29/2010 4:49 PM: > Is it possible to force samba server to write data to the disk and not > cache it at-all? If yes, is there a config option for this? BAsically, > I would like to emulate iozone "-o" option on the server side itself > (without having iozone do -o)? You may want to read this. I assume you know who Linux Torvalds is, yes? http://kerneltrap.org/node/7563 -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] max smbd processes
Jeremy Allison put forth on 1/27/2010 7:20 PM: > On Wed, Jan 27, 2010 at 06:21:36PM -0600, Stan Hoeppner wrote: >> I noticed in the documentation I quoted earlier something about running Samba >> from inetd. Is this (easily) doable? Would running from inetd be >> advantageous >> in my low resource consumption scenario, processes exiting after a period of >> inactivity? Or would this cause more problems than it would solve? > > Should work. Log a bug if it doesn't. It will also prevent the > backend printer smbd from running as well. I'd never dug into inetd.conf before today. Luckily I've got smbd working via inetd now. I didn't configure nmbd in inetd as I don't really need browsing. I have netbios disabled everywhere anyway so it's of little use. So, this is great, exactly what I was looking for. When I click my mapped drive(s) in Windows, a single smbd process fires on the Debian host, and it works, just as it should. I've not rebooted the system since making the inetd changes, merely killing inetd with -HUP to reload its config. The Samba init script is still going to be run during the next boot as I haven't monkeyed with the rcX.d directories or anything. I set RUN_MODE="inetd" in the /etc/init.d/samba script. Will that change by itself keep the script from launching the normal set of daemon processes or is there something else I need to do to prevent this and have inetd handle it all? >> P.S. We briefly met once a few years ago when you were in St. Louis. You >> stopped by Whitfield School to troubleshoot an issue with the AD code. I was >> the sysadmin there at the time. You were working for Novell at that time. > > Oh that's great ! I am actually wearing my green Whitfield School fleese > right now ! It's one of my favourite items of clothing :-). I guess that clothing is better than the name it bears. Do you wear any of your Novell clothing? If not, you'll understand why I no longer wear any of my Whitfield clothing. ;) However, I'm glad I was working there at that time, as it offered me the rare opportunity to meet one of the great wizards in the FOSS realm. ;) I must admit I haven't kept tabs on you since you left Novell and landed at Google. I just recently joined the samba list (should have long ago). I noticed the listserv seems to be hosted in Utah. Are you still living in the mountains or did you migrate to the Bay Area? Novell has its problems, but one has to admit they picked a spot with one heck of view for their HQ. I was there for Brainshare '07. The view of those mountains almost made me want to move there. Then I came to my senses when taking the local religion factor into account. ;) Sorry I'm getting OT. I guess we could pick up the reminiscing off list. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] max smbd processes
Jeremy Allison put forth on 1/27/2010 5:18 PM: >> Is "max smbd processes" not an accurate description? Would it better >> be described as "max smbd concurrent clients" or "max smbd user processes"? > > Yes, that's a better description. Understood. > There's also the printer background lpq updater process, that's the > third one. We should probably update the description to make this > clear. It's all working as designed. You can always comment out > the code for this (it's in printing/printing.c:start_background_queue()) > if you are resource constrained. Aha, so that's what the third one is. As I don't do printer sharing this possibility slipped my mind. I'm not so resource constrained as to start hacking source. I always stick with my distro's packages unless extreme circumstances require going to source, and this really isn't one of them. Maybe there could be a future smb.conf option to completely disable printer sharing and the launch of the deamon process? I noticed in the documentation I quoted earlier something about running Samba from inetd. Is this (easily) doable? Would running from inetd be advantageous in my low resource consumption scenario, processes exiting after a period of inactivity? Or would this cause more problems than it would solve? Thanks Jeremy. -- Stan P.S. We briefly met once a few years ago when you were in St. Louis. You stopped by Whitfield School to troubleshoot an issue with the AD code. I was the sysadmin there at the time. You were working for Novell at that time. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] max smbd processes
Samba 3.2.5 on Debian Lenny From: http://www.samba.org/samba/docs/server_security.html "Samba is able to limit the number of concurrent connections when smbd is launched as a daemon (not from inetd). The 'max smbd processes' smb.conf option allows Administrators to define the maximum number of smbd processes running at any given point in time. Any further attempts from clients to connect to the server will be rejected." I'm using max smbd processes for another reason. I'm trying to optimize memory usage on this box, which really only ever has one samba client machine connecting. I'm trying to get the number of smbd processes down to 1 but to this point have failed. I have in /etc/samba/smb.conf: max smbd processes = 1 Yet once restarting samba and connecting to a share, I get this: [04:41:16][r...@greer]/$ ps -ef|grep smbd root 8586 1 0 00:12 ?00:00:00 /usr/sbin/smbd -D root 8591 8586 0 00:12 ?00:00:00 /usr/sbin/smbd -D stan 8596 8586 0 00:13 ?00:00:56 /usr/sbin/smbd -D top: 8586 root 20 0 12368 2828 2168 S0 0.7 0:00.12 smbd 8591 root 20 0 12368 984 340 S0 0.3 0:00.00 smbd 8596 stan 20 0 12912 3972 2896 S0 1.0 0:56.46 smbd I've set max smbd processes to 1, yet I see 3 smbd processes. Is something broken? Is "max smbd processes" not an accurate description? Would it better be described as "max smbd concurrent clients" or "max smbd user processes"? I can understand the need for a master daemon process that spawns children for each connection, but at most that should require 2 smbd processes, not 3. As you can see from the top output, only one smbd process is actually servicing a client. One is completely idle, sucking up resources. The other appears to be the master which spawns the children. I know I'm in a fringe scenario here, as most people aren't going to try to limit smbd processes to 1. I'm just wondering why the documentation is so exactly specific as to the nature of this config option, but why the option doesn't work the way it is described. Is this a "truth in advertising" issue, or am I missing something else in my config to make this config directive work as advertised? Thanks. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)
Stan Hoeppner put forth on 1/25/2010 5:30 PM: > Volker Lendecke put forth on 1/25/2010 1:28 AM: >> The dual-stream one is kindof limited help. The interesting >> piece is how Win->Win does its thing faster, so we need to >> see that one. > > I've been busting my but trying to get you something meaningful. This dump is > less than optimal for two reasons, but it's the best I can get you thus far. > > 1. Running tshark on Win2K creates a huge network performance hit and thus > b/w > numbers for small file (<250MB) transfers don't come close to accurately > describing the real world. With tshark running the b/w is less than half of > normal with small files. > > 2. Because of this I had to do a huge file copy to allow time for the client > to > level off at peak performance, which is still ~500KB/s lower than normal due > to > tshark overhead. > > Anyway, the file is over 400MB. It'll take quite a while to grab off my > server. > > http://www.hardwarefreak.com/smb-winwin-single-stream > > Hope you are able to glean something meaningful from it. Were you able to grab this trace file yet Volker? If so, have you found anything interesting yet when comparing it to the previous Samba->Win2K trace file? Any clues yet as to why the win-win throughput is almost 3MB/s better than Samba->Win? If you haven't dug into it yet, as a reminder, this last trace capture was done with tshark on windows. The previous trace file was captured on the Linux machine with tcpdump. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)
Volker Lendecke put forth on 1/25/2010 1:28 AM: > On Mon, Jan 25, 2010 at 12:14:36AM -0600, Stan Hoeppner wrote: >> Volker Lendecke put forth on 1/24/2010 6:51 AM: >>> On Sun, Jan 24, 2010 at 02:09:51PM +0200, Michael Wood wrote: >>>> Except that he said "I can copy files between the Win2K and WinXP >>>> machines at just over 10MB/s in a single stream and max out the 11MB/s >>>> with two streams." I am assuming he used the same client in that test >>>> as he did with the test against Samba. So from what he's said it >>>> seems that he gets more speed with a Windows server than with Samba >>>> for the same client. >>> >>> So what we need is a full network trace of both cases. >> >> Actually I'll give you something slightly different, and more to the original >> question. I've taken two tcp captures on the Samba server machine. Both >> transfers were performed using the Windows 2000 cli "copy" command pulling a >> 36MB avi file from a share on the Samba server. The first test was a single >> stream copy. The second test was a dual stream copy of the same file >> concurrently to two different destination directories. I also had iftop >> running >> during the tests. The single stream transfer maxed out at just over 64Mb/s. >> The dual stream test maxed out at 92Mb/s. Following are the two tcpdump >> output >> files using "tcpdump -p -s 0 -w FILE port 445": >> >> http://www.hardwarefreak.com/smb_single_stream >> http://www.hardwarefreak.com/smb_dual_stream > > The dual-stream one is kindof limited help. The interesting > piece is how Win->Win does its thing faster, so we need to > see that one. I've been busting my but trying to get you something meaningful. This dump is less than optimal for two reasons, but it's the best I can get you thus far. 1. Running tshark on Win2K creates a huge network performance hit and thus b/w numbers for small file (<250MB) transfers don't come close to accurately describing the real world. With tshark running the b/w is less than half of normal with small files. 2. Because of this I had to do a huge file copy to allow time for the client to level off at peak performance, which is still ~500KB/s lower than normal due to tshark overhead. Anyway, the file is over 400MB. It'll take quite a while to grab off my server. http://www.hardwarefreak.com/smb-winwin-single-stream Hope you are able to glean something meaningful from it. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)
Stan Hoeppner put forth on 1/25/2010 12:07 PM: > Volker Lendecke put forth on 1/25/2010 1:28 AM: >> On Mon, Jan 25, 2010 at 12:14:36AM -0600, Stan Hoeppner wrote: >>> Volker Lendecke put forth on 1/24/2010 6:51 AM: >>>> On Sun, Jan 24, 2010 at 02:09:51PM +0200, Michael Wood wrote: >>>>> Except that he said "I can copy files between the Win2K and WinXP >>>>> machines at just over 10MB/s in a single stream and max out the 11MB/s >>>>> with two streams." I am assuming he used the same client in that test >>>>> as he did with the test against Samba. So from what he's said it >>>>> seems that he gets more speed with a Windows server than with Samba >>>>> for the same client. >>>> >>>> So what we need is a full network trace of both cases. >>> >>> Actually I'll give you something slightly different, and more to the >>> original >>> question. I've taken two tcp captures on the Samba server machine. Both >>> transfers were performed using the Windows 2000 cli "copy" command pulling a >>> 36MB avi file from a share on the Samba server. The first test was a single >>> stream copy. The second test was a dual stream copy of the same file >>> concurrently to two different destination directories. I also had iftop >>> running >>> during the tests. The single stream transfer maxed out at just over 64Mb/s. >>> The dual stream test maxed out at 92Mb/s. Following are the two tcpdump >>> output >>> files using "tcpdump -p -s 0 -w FILE port 445": >>> >>> http://www.hardwarefreak.com/smb_single_stream >>> http://www.hardwarefreak.com/smb_dual_stream >> >> The dual-stream one is kindof limited help. The interesting >> piece is how Win->Win does its thing faster, so we need to >> see that one. > > I think something is wrong. I downloaded Wireshark Win32. When running > > tshark -p -w smb-winwin-single-stream port 445 > > the transfer rate is half what it is without Wireshark running. What am I > doing > wrong? This is rather interesting, and disheartening. I've just spent 30 minutes playing with tshark and windump. For small file transfers, the presence of the capture tools running cuts the network interface performance in half. If I copy a 600MB file, the rate gradually increases to 10MB/s but only after about 45 seconds. Given my limited outbound, I doubt anyone wishes to try to download a 600MB file from my server, nor analyze the contents of such a behemoth. What Windows capture tool is available that does not itself *cause* a further performance problem in the act of capturing the data to solve one? This is a ridiculous situation. This machine has a 2GHz AthlonXP CPU, 1GB RAM, and a 120GB 7200RPM IDE disk. CPU for tshark or windump never exceeds 25%. Why are these capture tools doing this? They've created a catch 22. I can't report the data without the capture, but the capture ruins the data. This is very, very frustrating. tcpdump on Debian has no such problems, and that machine is a lowly dual 550 with only 384MB of PC100. However, it's Linux instead of Windows, which helps tremendously. And, it's got an Intel Pro 100 server adapter in it whereas the workstation has an integrated nVidia nForce2 MCP 10/100 motherboard down NIC. Please help alleviate the frustration here and get me back on the path to solving this performance issue. Thanks. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)
Volker Lendecke put forth on 1/25/2010 1:28 AM: > On Mon, Jan 25, 2010 at 12:14:36AM -0600, Stan Hoeppner wrote: >> Volker Lendecke put forth on 1/24/2010 6:51 AM: >>> On Sun, Jan 24, 2010 at 02:09:51PM +0200, Michael Wood wrote: >>>> Except that he said "I can copy files between the Win2K and WinXP >>>> machines at just over 10MB/s in a single stream and max out the 11MB/s >>>> with two streams." I am assuming he used the same client in that test >>>> as he did with the test against Samba. So from what he's said it >>>> seems that he gets more speed with a Windows server than with Samba >>>> for the same client. >>> >>> So what we need is a full network trace of both cases. >> >> Actually I'll give you something slightly different, and more to the original >> question. I've taken two tcp captures on the Samba server machine. Both >> transfers were performed using the Windows 2000 cli "copy" command pulling a >> 36MB avi file from a share on the Samba server. The first test was a single >> stream copy. The second test was a dual stream copy of the same file >> concurrently to two different destination directories. I also had iftop >> running >> during the tests. The single stream transfer maxed out at just over 64Mb/s. >> The dual stream test maxed out at 92Mb/s. Following are the two tcpdump >> output >> files using "tcpdump -p -s 0 -w FILE port 445": >> >> http://www.hardwarefreak.com/smb_single_stream >> http://www.hardwarefreak.com/smb_dual_stream > > The dual-stream one is kindof limited help. The interesting > piece is how Win->Win does its thing faster, so we need to > see that one. I think something is wrong. I downloaded Wireshark Win32. When running tshark -p -w smb-winwin-single-stream port 445 the transfer rate is half what it is without Wireshark running. What am I doing wrong? Thanks. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)
Volker Lendecke put forth on 1/24/2010 6:51 AM: > On Sun, Jan 24, 2010 at 02:09:51PM +0200, Michael Wood wrote: >> Except that he said "I can copy files between the Win2K and WinXP >> machines at just over 10MB/s in a single stream and max out the 11MB/s >> with two streams." I am assuming he used the same client in that test >> as he did with the test against Samba. So from what he's said it >> seems that he gets more speed with a Windows server than with Samba >> for the same client. > > So what we need is a full network trace of both cases. Actually I'll give you something slightly different, and more to the original question. I've taken two tcp captures on the Samba server machine. Both transfers were performed using the Windows 2000 cli "copy" command pulling a 36MB avi file from a share on the Samba server. The first test was a single stream copy. The second test was a dual stream copy of the same file concurrently to two different destination directories. I also had iftop running during the tests. The single stream transfer maxed out at just over 64Mb/s. The dual stream test maxed out at 92Mb/s. Following are the two tcpdump output files using "tcpdump -p -s 0 -w FILE port 445": http://www.hardwarefreak.com/smb_single_stream http://www.hardwarefreak.com/smb_dual_stream The file sizes are 38MB and 76MB respectively. The raw outbound link speed behind which my web server sits is only 512Kb/s so it'll take a few minutes to pull the files, probably about 30-35 minutes or so for both files. My apologies for any inconvenience this may cause. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)
Volker Lendecke put forth on 1/24/2010 6:51 AM: > On Sun, Jan 24, 2010 at 02:09:51PM +0200, Michael Wood wrote: >> Except that he said "I can copy files between the Win2K and WinXP >> machines at just over 10MB/s in a single stream and max out the 11MB/s >> with two streams." I am assuming he used the same client in that test >> as he did with the test against Samba. So from what he's said it >> seems that he gets more speed with a Windows server than with Samba >> for the same client. > > So what we need is a full network trace of both cases. Exactly how would I perform such a task? With what utilities? Do you mean something like tcpdump on the Linux side? I'm not familiar with a Windows tool for the same. Can the Windows network monitor do this? I've never really used it. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)
Michael Wood put forth on 1/24/2010 6:09 AM: > 2010/1/24 Volker Lendecke : >> On Sat, Jan 23, 2010 at 02:11:04PM -0600, Stan Hoeppner wrote: >>> The 11MB/s was a different test, which I clearly stated. >>> It consisted of two concurrent single stream file copies >>> _from_ the Samba server _to_ a Win2K workstation using >>> standard Windows Explorer as the file copy program. This >>> test saturated one leg of the 100FDX ethernet connection >>> at ~11.5MB/s. >> >> Just a quick hint: Single stream performance really heavily >> depends on the concrete client behaviour. smbclient from 3.2 >> and higher should give you good performance. And watch out >> which program on the Windows client you use to do the copy. >> xcopy, robocopy and the Windows explorer on some OS version >> give dramatically different results. The difference comes >> from overlapping requests or their absence. > > Except that he said "I can copy files between the Win2K and WinXP > machines at just over 10MB/s in a single stream and max out the 11MB/s > with two streams." I am assuming he used the same client in that test > as he did with the test against Samba. So from what he's said it > seems that he gets more speed with a Windows server than with Samba > for the same client. This is correct. Except, just to be clear, the two Windows machines are both _client_ versions of MS Windows, not Windows Server. I eliminated my only remaining Windows server box a short wile ago, replacing it with the Samba server on much newer faster hardware. So, the environment consists of two Windows workstations and one Linux/Samba server (although it serves much more than just Samba). Almost all of my testing has been performed at the console of the Windows 2000 Professional workstation. The two remote test systems are Samba 3.2.5 on Debian Lenny and a Windows XP Home machine. I'm sure when you said Windows "server" you meant server in the SMB client/server relationship sense, but just in case I thought I'd clarify exactly what systems are involved to prevent possible confusion. So, ironically, these two Windows clients serve single stream SMB to one another faster than either of them to/from Samba. I'm glad more people are getting involved in this thread because it's making me look at things I previously had not (though should have). I just checked and found that the two Windows clients are talking to each other over TCP 445 which is SMB over TCP/IP without NETBIOS. Until just a few minutes ago, my Windows 2000 Pro machine had NETBIOS over TCP/IP enabled, and was only talking to the Samba server over TCP 139. Thinking this might make a slight difference, and to make my testing as close to apples-apples as I can, I disabled NETBIOS over TCP/IP, and now the Win2K workstation is connecting to Samba over only TCP 445. However, I ran the file transfer tests again, and there was no change in single stream performance--still 8MB/s up and down. I hope that whatever the cause of this 3MB/s performance loss is that the solution is user configurable, in the Windows registry or in smb.conf. I've been trying to wean myself off Windows for years but so far only for server duties. I can't stand the thought that two Windows workstations will be faster xferring files between each other than to my sleek Debian Samba file server. I've spent hundreds of hours tweaking the performance of my Debian server, and it's fast as greased lightning for most everything except single stream Samba performance. I really want to remedy this situation. ;) -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)
Volker Lendecke put forth on 1/24/2010 5:04 AM: > On Sat, Jan 23, 2010 at 02:11:04PM -0600, Stan Hoeppner wrote: >> The 11MB/s was a different test, which I clearly stated. >> It consisted of two concurrent single stream file copies >> _from_ the Samba server _to_ a Win2K workstation using >> standard Windows Explorer as the file copy program. This >> test saturated one leg of the 100FDX ethernet connection >> at ~11.5MB/s. > > Just a quick hint: Single stream performance really heavily > depends on the concrete client behaviour. smbclient from 3.2 > and higher should give you good performance. And watch out > which program on the Windows client you use to do the copy. > xcopy, robocopy and the Windows explorer on some OS version > give dramatically different results. The difference comes > from overlapping requests or their absence. I just tested xcopy with the previously mentioned 600MB+ file between my Win2K Pro workstation and the WinXP workstation, single stream, both directions. I also did the same xcopy tests between the Win2K Pro workstation and the Samba server. The b/w results are identical to the previous Windows Explorer file copy tests, 8MB/s up/down to Samba, and a little over 10MB/s up/down to the WinXP machine. Are overlapping requests the cause of the single stream performance issue here? If so, are overlapping requests something that is negotiated in the SMB protocol between the hosts or is it statically configured, or something compiled into the client code? I.e. if overlapping requests is the issue, why do the two Windows machines seem to do it correctly between themselves, but the Windows/Samba combination does not? Is there something I can manually configure on Win2K Pro to overlap requests to/from Samba? Thanks for the assistance, insight, and education. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)
Stan Hoeppner put forth on 1/23/2010 2:11 PM: > Absolutely not. Both interfaces (Samba server and Win2K workstation) are > configured and confirmed to be operating in full duplex mode. I confirmed > this > by forcing the Win2k box to 100FDX. This broke the switch which wants full > autonegotiation, forcing the link to half duplex. It dropped performance by > over 60%. I reenabled full autonegotiation, and performed a test which I had > not previously. I launched two copy operations of the same ~600MB file, one > up, > one down, and according to NetMeter, was running ~7.5MB/s up to the Samba > server > and 6.5MB/s down to the workstation. Combined this is 14MB/s, more than a HDX > link can provide. I'm ashamed I can't get that close to the ideal 22MB/s. > There are two possibilities for this that I can think of: I just did some additional testing to see how FTP would perform with full duplex put/get to/from the xfs filesystem backing the Samba share for comparison to Samba performance. I used two sessions of the Windows 2000 inbuilt FTP command line client with default settings. I used the same 600MB+ file up/down, two copies, different names. full duplex get/put: get ftp: 678624350 bytes received in 65.92Seconds 10294.35Kbytes/sec. put ftp: 678624350 bytes sent in 89.88Seconds 7550.76Kbytes/sec. one way get: get ftp: 678624350 bytes received in 57.84Seconds 11731.97Kbytes/sec. The up/down is very uneven with the concurrent ftp transfers, downloads receiving more b/w than up. ProFTPD doesn't balance or shape traffic by default. I looked into using mod_shaper but it's not compiled into the Debian ProFTP daemon, and frankly I have no use for the traffic shaper beyond this testing. The headache of installing it or another ftp daemon which does shaping is more hassle than it's worth at this point. Anyway, as you can see from the numbers above, one transfer ran considerably longer than the other as it received less b/w during concurrency, about 25 seconds, which artificially inflates its transfer rate a bit as it gets all 11MB/s of the b/w for the remainder of its transfer after the other transfer has completed. With that caveat mentioned, I'll point out that watching the output of NetMeter during concurrency clearly showed a combined total of 16MB/s up+down. I ran the same test, same 600MB+ file, and traffic to/from Samba averages only 13MB/s. Remember, I'm reporting raw numbers, so protocol overhead is irrelevant. This testing demonstrates that due to one or multiple factors, hardware and/or software, my combined maximum full duplex throughput between my Win2K workstation and the Debian Lenny Samba server is approximately 16MB/s with my fastest applications tested to date, those being FTP client and server. Best one-way performance achieved to date is the maximum for switched fast ethernet, just over 11MB/s, obtained with FTP. Full duplex performance maximization would be great, but frankly it doesn't concern me as it is not one of my needs. What is a need is maximizing one-way single stream performance between the Samba server and my workstation. So, again, what can I do to bring my single stream raw transfer Win2K<->Debian Samba server performance up near the level of my FTP performance. FTP performance peaks at 11MB/s with a single stream yet SMB performance peaks at only 8MB/s single stream. Again, this is measuring raw packet performance on the interface, so protocol overhead is already in the numbers. Samba 3.2.5 or Win2K, or the combination of the two, simply will not saturate the interface with a single stream. With two streams going the same direction, they _do_ saturate the interface at 11MB/s. What's the solution to getting that last 3MB/s out of a single stream? Or, put a better way, that last 30% that's being left on the table. From other posts I've read here, people using GigE are also seeing something similar. They can't get that last 30% or so into the interface with a single stream. I don't think this problem is merely affecting me on Fast Ethernet. I guess I really needed the extra performance I could go buy some GigE cards (if they make them in regular PCI) and a GigE switch. However, I'd really just like to maximize what I already have, and not go spending money I don't want to. ;) -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)
Learner Study put forth on 1/23/2010 3:31 AM: > Hi Linda: > > Looking at some internet resources, it appears that both encryption > and packet signing are off by default. Can u pls let me know how to > disable these on samba server side (on 3.0.x) Pretty sure they are both off in my case. I did not enable them in smb.conf. > On Sat, Jan 23, 2010 at 12:48 AM, Linda Walsh wrote: >> Igor wrote: >>> >>> I don't find it strange at all. Your computer is acting as a traffic >>> proxy between two samba servers. If you have 100Mb network interface >>> your bandwidth should split exactly in two. >> >> But he said he doesn't get a split in two when a win2k server >> is used (he gets 11Mbps).I.e. Two network streams in two different >> directions should NOT halve throughput, _unless_ something is operating >> in half-duplex mode. "100Mbps, full duplex" should, _easily_, >> allow two 8 MBps streams if they are going in opposite directions. The 11MB/s was a different test, which I clearly stated. It consisted of two concurrent single stream file copies _from_ the Samba server _to_ a Win2K workstation using standard Windows Explorer as the file copy program. This test saturated one leg of the 100FDX ethernet connection at ~11.5MB/s. >> Stan wrote: >>> >>> Interestingly, if I launch a file copy with the SH> source file being >>> on one smb share on the server, and the destination being SH> another >>> smb share (separate filesystem) on the server, the combined throughput >>> SH> is also 8MB/s, 4 up and 4 down, which is very strange as this >>> should be two SH> distinct streams. >> >> --- >>I agree. Is it possible your network device isn't running in FULL >> duplex? Absolutely not. Both interfaces (Samba server and Win2K workstation) are configured and confirmed to be operating in full duplex mode. I confirmed this by forcing the Win2k box to 100FDX. This broke the switch which wants full autonegotiation, forcing the link to half duplex. It dropped performance by over 60%. I reenabled full autonegotiation, and performed a test which I had not previously. I launched two copy operations of the same ~600MB file, one up, one down, and according to NetMeter, was running ~7.5MB/s up to the Samba server and 6.5MB/s down to the workstation. Combined this is 14MB/s, more than a HDX link can provide. I'm ashamed I can't get that close to the ideal 22MB/s. There are two possibilities for this that I can think of: 1. The two switches involved are soho/consumer class, both unmanaged. One of the two is a $10 Rosewill (no name Chinese) 8 port desktop jobby. The other is a circa 2003/4 SMC rack mount combo 8port 100FDX switch and firewall router, which is a much better piece of gear, ran me about $100 in '03, but still pretty low end. The cost/quality of these two may or may not be a factor, but at this point I assume it might be. 2. The machines themselves may not be up to it, although I would think they should be given their specs, and that we're talking about merely 100FDX with a theoretical max of 12.5MB/s. This is something I'll investigate further, after I figure out the single stream problem. >>Other things to check (to optimize speed compared to ftp): >> >>1) Ensure your communications are using TCP (port 445) and not >> UDP (port 139). For raw bandwidth maximization, what port and protocol are used won't make much difference, if any. In fact it shouldn't make _any_ difference in raw b/w. Communications between the Samba server and Win2K client appear to be exclusively over TCP 139 at this point according to netstat, instead I'm misreading or looking in the wrong place. Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 0.0.0.0:139 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:445 0.0.0.0:* LISTEN tcp0 0 192.168.100.9:139 192.168.100.53:1128 ESTABLISHED udp0 0 192.168.100.9:137 0.0.0.0:* udp0 0 0.0.0.0:137 0.0.0.0:* udp0 0 192.168.100.9:138 0.0.0.0:* udp0 0 0.0.0.0:138 0.0.0.0:* >>2) Ensure encryption (Sealing) is off. >>3) Ensure packet Signing is off. I assume these are off by default. I didn't enable them in smb.conf. >> The overhead of 2 & 3 contribute to around a 15% performance hit according >> to 1 MS source. (Obviously turning such things off presumes you are on >> a 'safe' network consistent with FTP usage, vs. SCP/SSH). The network is private, thus safe in this context. I'm pretty sure both of my measuring tools are reporting raw bandwidth, iftop on Linux and NetMeter on Windows 2000, so even if there is SMB overhead in the mix, it's irrelevant at this point. My problem is I can't max out single stream _raw_ bandwidth to/from the Samba server. I'm only getting 65Mb/s raw with a single file copy. I get 92Mb/s with two
Re: [Samba] single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)
Igor put forth on 1/21/2010 6:04 PM: > Hello Stan, Hello Igor, > I don't find it strange at all. Your computer is acting as a traffic > proxy between two samba servers. If you have 100Mb network interface > your bandwidth should split exactly in two. Which should be 5.5MB/s instead of 4MB/s for each stream. I included this example for comparison, as an additional data point. It is not the thrust of my post, merely supporting data, as this should in theory be _two_ streams. > FTP is a different protocol. You might find the answer if you look at > the percentage the carrying protocol like SAMBA consumes out of the > traffic to support protocol integrity. You may find out that the rest 2Mb > (you should actually have no more than 10Mb/s at 100Mb interface) are > used by the carrying protocol itself. That somehow "though the protocol > itself allows" but "for the sake of connectivity" the maximum size of > the packet is set to 64К. Which is not surprising as far as Microsoft goes. I don't think you read my post thoroughly, or possibly I didn't state my case thoroughly or eloquently. _Two_ concurrent Windows file copy streams to/from the Samba share peak iftop at 92Mb/s. A single FTP get/put to the same share filesystem peaks iftop at 92Mb/s. A _single_ Windows file copy peaks iftop at 65Mb/s. I've performed these tests over 10 times with the same results. Why will _one_ Windows file copy stream to/from the Samba share not peak the interface? Why do _two_ concurrent streams peak the interface but not _one_? > I'm sure people around here might provide you with some data > about SAMBA efficiency, but just remembering what a big difference > 1000Mb Ethernet produces over 100Mb as far as SAMBA is concerned - > well my best guess it's not more that 80% of all traffic. 20% goes > for protocol support. Protocol efficiency doesn't even come into play here AFAICT. A single stream should easily max a 100Mbit pipe. I'm only able to max the pipe using two or more concurrent streams from the same host. One stream won't do it. I don't know if the problem is with Windows or with Samba, but I'd sure like to find out and fix it. My testing has eliminated both operating systems, their storage, and the raw network performance as degrading factors. The only thing left if the SMB/CFS engines on both systems, which seem to have no trouble at all clogging the pipe with multiple streams, but run along lazily at 65% of peak when only one stream is present. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)
Hello fellow Samba users and devs. This is my first post. I've searched documentation far and wide for Windows, Linux, and Samba, and have not been able to shed any light on this issue. I can't get more than 8MB/s during a single file copy stream out of my Samba server over my 100FDX switched network either from Win2K or WinXP (I don't have a *nix client to test with). The network is idle during testing. Via FTP on these Win machines to/from the same filesystem (100GB XFS) as the Samba share I consistently get just a shade over 11MB/s. However, if I launch two simultaneous file copy streams from Windows Explorer or from the command line, I hit the 11MB/s I see via FTP. Interestingly, if I launch a file copy with the source file being on one smb share on the server, and the destination being another smb share (separate filesystem) on the server, the combined throughput is also 8MB/s, 4 up and 4 down, which is very strange as this should be two distinct streams. I can copy files between the Win2K and WinXP machines at just over 10MB/s in a single stream and max out the 11MB/s with two streams. I've tweaked every relevant Windows registry setting I can identify, and I've tried all combination of the following smb.conf settings with various buffer sizes max xmit = 65535 socket options = TCP_NODELAY socket options = SO_SNDBUF=262144 SO_RCVBUF=262144 socket options = IPTOS_LOWDELAY and none of these tweaks make a difference. Still only 8MB/s with a single stream. I've eliminated the network hardware and any CPU/mem/disk bottlenecks on the server and workstations as possible causes. The machines are all much more powerful than the minimums required to fully saturate a 100FDX network. I don't know if the problem lies with the Windows clients or with smbd. The one thing that is certain is that this is a single stream performance issue. Launching multiple copy streams maxes the network just as FTP does. Why is 3MB/s of free bandwidth being left on the table for single stream operations to from smbd? Any/all hints comments are welcome. I've burned many hours on trying to figure this out to no avail, and if I had any hair I'm sure I'd have pulled much of it out troubleshooting this. ;) I'd really like to max out that single stream performance. Thanks. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
