NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
4.1.7 Slow To Respond To SMB Network Discovery...
Hi,
Since upgrading my DUO to 4.1.7 I have noticed that the DUO is *very* slow to respond SMB/SAMBA network share enumeration requests. It may take up to about a minute for the DUO to provide its list of shares. The problem happens *every* time the DUO is asked to list its shares and not just for the first request. This was not an issue under 4.1.6. (I never ran any of the betas and upgraded from 4.1.6 production directly to 4.1.7 production. There were no obvious issues with the upgrade.)
On a client PC this results in about a minute of waiting before the DUO responds with a share list. This is long but not particularly problematic. On the other hand, to my media players this response is *so* long that the media player times out and is no longer able to find the DUO. This is *very* problematic.
This is only happening on my DUO with 4.1.7. The same DUO with 4.1.6 was fine and my NVX with 4.2.15 is also fine.
Is it possible to get a patch to repair this issue? Is there anything I can do to restore the previously snappy performance? Is it safe/possible to revert to 4.1.6?
Regards,
Ian.
Since upgrading my DUO to 4.1.7 I have noticed that the DUO is *very* slow to respond SMB/SAMBA network share enumeration requests. It may take up to about a minute for the DUO to provide its list of shares. The problem happens *every* time the DUO is asked to list its shares and not just for the first request. This was not an issue under 4.1.6. (I never ran any of the betas and upgraded from 4.1.6 production directly to 4.1.7 production. There were no obvious issues with the upgrade.)
On a client PC this results in about a minute of waiting before the DUO responds with a share list. This is long but not particularly problematic. On the other hand, to my media players this response is *so* long that the media player times out and is no longer able to find the DUO. This is *very* problematic.
This is only happening on my DUO with 4.1.7. The same DUO with 4.1.6 was fine and my NVX with 4.2.15 is also fine.
Is it possible to get a patch to repair this issue? Is there anything I can do to restore the previously snappy performance? Is it safe/possible to revert to 4.1.6?
Regards,
Ian.
179 Replies
Replies have been turned off for this discussion
- The NoSMBDisconnect add-on makes a reversible configuration change. It's not risky to run and many users have found it to be helpful on several versions of RAIDiator. Unless you have a huge number of users you probably won't have any issues using this add-on.
mdgm wrote: The NoSMBDisconnect add-on makes a reversible configuration change. It's not risky to run and many users have found it to be helpful on several versions of RAIDiator. Unless you have a huge number of users you probably won't have any issues using this add-on.
This will not resolve the problem: the first SMB access of every PC will still be slow. Only subsequent requests will be faster. And I do not know about negative impacts caused by not releasing unused resources on the NAS; that sounds like a resource leak situation which can only be resolved by rebooting the NAS. That's then worse than the current situation: all I need to do now is to toggle the CIFS service once after I've restarted the NAS; then all(!) PCs will be able to access all shares w/o any delay from the very first time.
I suspect that there's an issue with the boot sequence. Maybe samba is started too early. If it is started last, no problems occur.
Actually, Sean has mentioned this suspect already in December 2010:Jedi Knight,
This behavior suggests that a change in the way the new firmware boots the device has a damaging effect on the CIFS/SMB discovery mechanism. Please forward this issue to the appropriate team such that we can all enjoy a fix as soon as possible.
Thanks,
SeanWSJ wrote: Milhouse wrote: Reverting to 4.1.6 may be a viable option for some users. Given all the reports of issues with 4.1.7 I decided to stay on 4.1.6 despite wanting (but not needing) some of the enhancements in 4.1.7, and as every day passes without any sign of progress I'm more and more glad I did.
Well, for me those new features (lower fan RPM on disk spin-down, support for larger disks) are important.
Furthermore it's not really an option to stay on an outdated version - just because the latest version is buggy and the vendor seems to be unwilling to fix the bugs. I do not want to decide between missing features and unfixed problems - why should I make any comprimises?
I still have two more years of guaranteed warranty.
Of course and I absolutely agree it's not a long term solution, but it may be a stop-gap solution for those users who have hit this problem and who aren't so dependent on the latest features. Also consider that some users may have received their ReadyNAS with 4.1.7 pre-installed and switching back to 4.1.6 may be the only solution between being able to reliably access their storage day in, day out, and being able to access it only intermittently.
Personally speaking I'll be surprised if there's another post-4.1.7 release in the pipeline, but given how far things have slipped since the Netgear take-over that's probably just as well. :(- Hi,
My initial testing of the new 4.1.8-T5 beta RAIDiator seems to indicate that this issue has been improved if not resolved. This is *not* documented in the beta notes fix list.
Can others with this problem please try the beta, if practical, and let us know if this beta addresses the issues in your environment.
Regards,
Ian. IanSav wrote:
My initial testing of the new 4.1.8-T5 beta RAIDiator seems to indicate that this issue has been improved if not resolved.
That sounds promising - I was not aware of a 4.1.8 beta until now.
Sounds like a belated birthday present ... :slap:IanSav wrote:
This is *not* documented beta notes fix list.
I wonder if that is because the issue hasn't been specifically addressed? Lack of any acknowledgement of the issue or other feedback, and the suggestion to try the SMBNoDisconnect addon in the last week which seemed to be a guess (and one that no one has reported to have fixed the issue) leads me to conclude that this may be happy coincidence?
Just speculating: the fact that restarting CIFS fixed the issue under 4.1.7 suggests the root cause was related to some change in the NAS boot sequence vs 4.1.6. Wouldn't be a big surprise if that boot sequence has perhaps again changed in 4.1.8 so avoiding the cause whatever it may have been.
FYI: If the issue does come back, there is a simple way to enable automatically bouncing the CIFS service on reboot rather than you have to go into Frontview and do it manually. Not a real solution, but a reasonable workaround.- Hi Sphardy,
It is possible that some changes were made as a result of a series of PMs I have been having with Netgear staff. I suspect the fixes may be documented when it is confirmed that they fix the problem.
Regards,
Ian. IanSav wrote:
It is possible that some changes were made as a result of a series of PMs I have been having with Netgear staff.
That's very good to knowsphardy wrote: Just speculating: the fact that restarting CIFS fixed the issue under 4.1.7 suggests the root cause was related to some change in the NAS boot sequence vs 4.1.6. Wouldn't be a big surprise if that boot sequence has perhaps again changed in 4.1.8 so avoiding the cause whatever it may have been.
I totally agree - the root cause of the issue was not found, but as a side-effect of other changes me might be lucky and the problem went away (similiar to how it was "introduced" with 4.1.7 - as a side-effect with unclear root cause). At least, Netgear is honest - they did not state that they have "fixed" the problem. Anyway - if the final version of 4.1.8. is also free of that bug, then that's a happy end. 8)IanSav wrote: Hi,
My initial testing of the new 4.1.8-T5 beta RAIDiator seems to indicate that this issue has been improved if not resolved. This is *not* documented beta notes fix list.
Can others with this problem please try the beta, if practical, and let us know if this beta addresses the issues in your environment.
Regards,
Ian.
Based on Ian's feedback, I've decided to give a try, as well. And I can confirm his good news.
So, everybody who is currently using 4.1.7 and suffering from the bug described in this thread: it's better to upgrade to 4.1.8 than to return back to 4.1.6. Whether you wait for the final version or dare to use the beta, is of course up to you. I was daring - and did not regret it (so far).
Regards, Wolfgang
PS: I'd appreciate if some of you would join Ian and me in testing the beta (click here) - the more of you are willing to give feedback the more likely it is that 4.1.8 will be released officially, soon.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
