First, let me say a big THANK YOU for upgrading the Samba to a version that supports SMB2. Several friends and myself had all manually upgraded to Samba 3.6.1 (and then to 3.6.3) in order to make iTunes usable. TimeMachine now finally appears to work for my husband's MacOS Lion laptop as well. It's great to have a supported solution.
Unfortunately, after the upgrade I am having multiple problems: -the shares are no longer browsable. start+run->"\\nas" results in a failure. -from my win7 login, I can browse to "\\nas\matt" and see the directory listing, but on the same machine, switching users and trying to browse to \\nas\geoff does not work at all (trying with IP address doesn't help). the directories are still there under /c/, and re-running smbpasswd doesn't help. -under \\matt\nas, it takes minutes to load a 1MB JPG. this used to be instantaneous.
I've double-checked and cleaned up the Samba 3.6.x install (based on the flumps.org instructions), and there doesn't appear to be any conflicts.
One of the reasons we chose Samba 3.6.x was that 3.5.11 did not appear to be stable using SMB2 with mixed Vista/Win7 clients over the course of a few weeks. Maybe a final bump to 3.5.13 will fix the issues we saw, but 3.6.x is the only version they say has reasonably complete SMB2 support.
So, I'll be jumping back to samba-3.6.3, which allowed my iTunes library to be hosted on a samba share and quickly sync my iPad/iPhone. With 3.6.3 and a few config tweaks, my iPhone/iPad sync times went from literal days (sometimes without completing) to hours. (I'm running iTunes 10.6 on win7/x64.)
I'm happy to provide logs, or even remote shell access to aid in debugging. Or, if you guys are in the bay area, I can bring in my ReadyNAS unit. This is a fixable problem, just a matter of figuring out how to get the installable image to get there 🙂
Thanks again!
PS: When can we expect a similar bump to the openssl0.9.8u package and to the OpenSSH 5.x package?
Ok, hang on a sec. What exactly are you installing samba 3.6.x on? If you're installing it on the ReadyNAS, then it's not an issue with T-6. If you're using it as a client on something else, we might be able to do something if we knew what that "something else" was, since all I can see mentioned is a windows 7 machine, and a mac running OSX lion.
I had previously upgraded the Samba on my ReadNAS Duo v1 running 4.1.8 from v3.0.x to v3.6.3. This was to fix intolerable performance issues when syncing iTunes with the Music Library hosted on the ReadyNAS using both 32-bit Vista SP1 and 64-bit Windows 7. My sync times went from 3+ days to less than 3 hours. A separate use case that was not working well was that my husband's MacOS laptop's Time Machine application could not see the ReadyNAS. It was while investigating manually upgrading that package that I saw this beta release.
Interested to try this beta so I could potentially have a supported solution, I downgraded the Samba back to v3.0.x and verified the performance problems came back. I then tried the 4.1.9-T6 beta image. While the latter use case involving Time Machine was fixed, the former case with iTunes and general Samba browsing got even worse.
Before I had settled on upgrading the ReadyNAS' Samba to 3.6.x, I had tried 3.5.x. I found that it's SMB2 implementation wasn't complete enough to solve the iTunes issues. It's possible that since 4.1.9-T6 is using 3.5.x, some of my problems are coming down to that. Either way, I'm happy to provide any logs or even remote shell access so you can take what has worked well for me and deliver it to the rest of your customer base. As I mentioned before, if you guys are in the SF bay area, I'm happy to bring the NAS into your offices to demonstrate.
I hope this is clearer than my earlier brain dump 🙂 Thanks!
SMB2 support in Samba 3.5.x is not production-ready. How did you come to the conclusion that you need SMB2 support? In general it is no faster than SMB1, and on a low-power machine like the Duo, it will almost always be slower -- perhaps significantly slower. Are you sure you're using SMB2? It requires configuration changes to enable it on both Samba 3.5 and 3.6.
After researching and experimenting for months with jumbo frames, socket options, and other things that made small differences, turning on SMB2 seemed to be the last thing that resolved my problem. That being said, when I then worked backward -- keeping SMB2 enabled while reverting other configuration changes -- the improvements were diminished. Here is an excerpt of the diff between the original smb.conf and the new one I was using: 24a25 > max protocol = SMB2 28c29 < oplocks = 0 --- > oplocks = 1 30a32 > read size = 32768 33a36 > socket options = TCP_NODELAY
I was rebooting the ReadyNAS and my client machine running iTunes between each configuration change, using both browsing to a directory of photos and viewing them and starting up iTunes and syncing my iPhone as test scenarios.
I am aware that turning on SMB2 support does increase overall CPU usage, and shows a slight dip in raw throughput, but the two use cases above were dramatically improved. Since I knew I was buying a consumer-level NAS, I am expecting more of a focus on usability and interoperability than raw performance (not that those things are mutually exclusive). CPU does appear to be the bottleneck right now, so I've bootstrapped GCC 4.7.0 (which includes --with-tune=leon support) and will be rebuilding samba-3.6.3 with LTO support to see what effect that has on overall throughput. (In my experiences at several well-known networking companies, using -O3 -flto with GCC 4.6.x both increased throughput by ~5%, lowered CPU usage by ~10%, and decreased binary size by 10-20% on both MIPS- and x64-based products.)
Again, let me know if there's any information I can provide so that you guys can reproduce either the problems or improvements. This is my main project while I'm unemployed for a few more weeks, but beyond that my time will be more limited 🙂
It is beta related, insofar as the Samba version/config in T6 is significantly worse than it was with Samba 3.0.x that came with 4.1.8. Browsing to a directory of photos in Win7/x64 takes a looong time, and selecting a photo and pressing enter results in a wait time of *10 minutes* for the photo to show. With 4.1.8's stock samba, directory browsing and photo viewing was nowhere near this bad.
This is in contrast to the noticeably improved AFP support in T6 versus 4.1.8.
let me know what information I can provide that will help you track down the regression between 4.1.8's stock samba and the new samba/config in 4.1.9-T6.
The thing is that since you have installed samba yourself (even though you've removed it) it's difficult to be sure if the issue is beta related. It could very well be related to the installation of samba you made and if it is NetGear can't be expected to help with that. Now if you were to backup all the data on your unit, do a factory default (wipes all data, settings, everything) and still find the issue that would be a different matter.
matt_hargett, as mdgm pointed out, this is not a beta issue. We did not do any internal testing with that version of samba, nor can we verify that you installed it correctly(even the website you mentioned previously only had instructions for installing an older version). I'm not saying you can't work with other users to resolve whatever issues you might have by installing unsupported software, but because of that it is not a beta issue.
The thing is that since you have installed samba yourself (even though you've removed it) it's difficult to be sure if the issue is beta related. It could very well be related to the installation of samba you made and if it is NetGear can't be expected to help with that. Now if you were to backup all the data on your unit, do a factory default (wipes all data, settings, everything) and still find the issue that would be a different matter.
can certainly do the reset and then retest. I'll post tomorrow with the results from that testing.
I hope that my positive feedback about AFP isn't questioned as aggressively. It's odd to see such a combative tone on a support forum of paying customers who are going above and beyond to provide useful feedback and in-depth debugging. I guess it's better than being ignored like the dozens of people who are having SqueezeCenter/Logitech Media Server issues on the ReadyNAS platforms for the last few years.
i'll post again tomorrow with the results from the full reset.
If you're using the version that's included in the T-6 build, that's fine. It's not like I'm trying to argue. Let me put it this way. let's say Honda gives you a new car to test and wants to know how it works. But the first thing you do is swap the engine out, then tell them the car no longer starts. They can't do anything with that. Does it make sense now why we can't consider manually changing the samba version to something different as a beta issue?
Your feedback about the improved AFP support seems about as expected compared to other people(and it is appreciated), and we are aware of the issue some people have reported with AFP requiring a 2nd connection before working.
After researching and experimenting for months with jumbo frames, socket options, and other things that made small differences, turning on SMB2 seemed to be the last thing that resolved my problem. That being said, when I then worked backward -- keeping SMB2 enabled while reverting other configuration changes -- the improvements were diminished. Here is an excerpt of the diff between the original smb.conf and the new one I was using:
So when you were using the Samba 3.5 from 4.1.9-T6, did you disable SMB2? You would also have to reboot the Windows client to stop using SMB2, because Windows tends to remember that we used to support it from its initial negotiation, and keeps using it -- and Samba will go along with it, even if max protocol is set to NT1.
Also, how many image files are in your test directory when it takes 10 minutes to display a single image? Is this over a wired or wireless connection?
Ah, that appeared to be the problem: I turned off smb2 then bounced samba and winbind, but didn't reboot the Win7 client machine. After a reboot, things are working *beautifully*. Thanks so much for your patience as I relayed my complicated story! 🙂
I'll keep testing over the next few days and let you know if I run into any issues. I am already noticing that with jumbo frames turned on and the aforementioned diffs, CPU still appears to be the bottleneck. Is there a source package for the samba version you guys are bundling? 'apt-get source samba' retrieves the stock Debian version, and adding a deb-src entry to the ReadyNAS package site doesn't work.
Will there be an OpenSSH/OpenSSL update in the next beta, as also provided on flumps.org?
