4.1.7 Slow To Respond To SMB Network Discovery...

[IanSav]

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.

[Berkhout]

Hello,

I got exactly the same problem with my Duo after ugrade to 4.1.7


greetings Berkhout

[rclark]

I've noticed similar behavior on a couple of NV+ units as well on both Win XP & Win 7 clients. Opening up My Computer for the first time with drives mapped to the NAS can take anywhere from 20-30+ seconds.

-Randy

[emk1]

I also have noticed slower response. Please note that I had 60 minute spin down timers set before the upgrade to 4.1.7 and continue to have those timers in place.
I have drive letters mapped on my vista box. On 4.1.6 when clicking on a network drive letter it was almost immediate, regardless of the spin down timers. Now on 4.1.7 I can wait up to 20 seconds before the contents of the drive are displayed and available to use. Definately something in the 4.1.7 upgrade that is doing this...

[IanSav]

Hi,

Can one of the Jedis please let us know if this problem is being investigated and how far the investigation has advanced? It would also be helpful if we can have an indication of how long it will take for this to be fixed.

With my DUO holding lots of material for my media players I will need to revert firmware if this isn't fixed quickly. (I would welcome advice of any issues reverting from 4.1.7 production back to 4.1.6 production.)

By the way, where can we get the 4.1.6 production version of the firmware? It doesn't appear to be available on the ReadyNAS website.

Regards,
Ian.

[tenortim]

I have the same issue. Performance was fine before the 4.1.7 upgrade and now the enumeration is so slow, I cannot mount any filesystems via cifsfs from a Linux box because it times out. Windows is able to perform the mounts, but the initial enumeration is appallingly slow. I'd rather not have to downgrade to 4.1.6, but this problem may force me to do so 😞

For the record, with is an NV with 1GB of memory and 4 1.5GB Seagate drives.

[jeremydo]

I think I have the same problem - after upgrading my nv+ to 4.1.7, my macintosh clients (using cifs/smb) see the server and allow me to browse to the top couple of directories on it, but as soon as I try to list a directory that has a lot of files (several hundred) or perform actions that access multiple files, the mac times out and kills the smb connection. Here's what I see in the system log file on the mac:

Dec 3 08:16:50 myhostname KernelEventAgent[36]: tid 00000000 type 'smbfs', mounted on '/Volumes/mysharename', from '//GUEST:@myreadynasname%20(CIFS)._smb._tcp.local/mysharename', dead

[mysharename, myhostname and myreadynasname are not the real names of course]

When I try to re-install 4.1.7 by using using "check for update, I get an error saying "error connecting to remote server".
I am ok reverting to 4.1.6, but can't find a .bin file for it. The 4.1.6 I can download from :
http://www.readynas.com/download/RAIDiator/RAIDiator-4.1.6 is not a valid image (when I try and do a local update).

note: i also have the ftp service enabled, and it seems to work ok (albeit slowly).

Any help to resolve this soon would be greatly appreciated,
Thanks,
Jeremy

[markhula]

Me to.
Directory listing from mac to nas ultra are real slow.
Any guru able to help?

[WSJ]

IanSav wrote:

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.)

I do have exactly the same problem - and I'm glad to read that I'm not the only one.
So, it's for very sure an issue with the upgrade.

I would appreciate if this bug would be fixed, soon.
(Would be a nice Xmas present ... - I hope that someone got the hint)

[IanSav]

Hi,

It seems there are a few of us observing this issue (and taken the time to post). I think a comment from Netgear is appropriate.

Regards,
Ian.

[WSJ]

IanSav wrote:
It seems there are a few of us observing this issue (and taken the time to post). I think a comment from Netgear is appropriate.

Yes, the least that they can do (instantaneously) is to publish how to downgrade to 4.1.6 - the last working version.
But I would prefer the bug to be fixed, of course.
4.1.7 has brought some improvements (the most important one for me: more silence - thanks to reduced fan speed after the disk spin-down).

[WSJ]

emk wrote:

I also have noticed slower response. Please note that I had 60 minute spin down timers set before the upgrade to 4.1.7 and continue to have those timers in place. I have drive letters mapped on my vista box. On 4.1.6 when clicking on a network drive letter it was almost immediate, regardless of the spin down timers. Now on 4.1.7 I can wait up to 20 seconds before the contents of the drive are displayed and available to use. Definately something in the 4.1.7 upgrade that is doing this...

I've noticed that also my printer is effected - so, it's not the disk spin down.
Printing is even more impacted; it nearly has become useless - at least for WLAN connected clients.
For the file shares the situation is the same for WLAN (54 Mbps) and LAN (1Gbps) - in both cases it's damned slow (takes about 20-30 seconds for SMB discovery; in comparison: my disks wake up in about 5 seconds).

[Jedi_Knight]

I wasn't able to reproduce the issue with my Mac 10.6.5, Windows XP and Windows Vista via GigE LAN. If you guys can send in the system logs, it may give us some clue here.

[arsenicrun]

I have three of these wonderful ReadyNAS Duos working for me on a gigabit LAN with a mix of Windows XP SP3 computers and Windows 7 computers accessing it. I upgraded two of the three Duos to the newest 4.1.7 firmware via the "Remote Upgrade" option in the web configuration interface, and since then those two Duos have been extremely slow to respond when mapping them as network drives or just browsing to them in both WinXP SP3 and Win7. The issue isn't intermittent, either, as I have encountered it 100% of the time I attempt to access the upgraded Duos after connecting my computer to the network. The Duo that I have not upgraded is still as instant as it ever was 🙂

Fortunately, once connected, throughput to and from the Duo hasn't been affected.

I'm afraid I have to agree with IanSav when I say this seems like an obvious enough issue that deserves some priority.

Thank you,
Sean

[jeremydo]

Which system logs ? for the client or the server ?
I am not able to ssh into my server.
I have had a small amount of success enabling afp and using that instead of smb, but it is still glacially slow - 90 seconds to do a directory listing. It almost seems like something else might be running in the background that is taking up a lot of cpu. But I can't tell what.

[markhula]

Me also.
Speed of file/directory access is bitterly painful.

[IanSav]

Hi Jedi Knight,

Jedi Knight wrote:
I wasn't able to reproduce the issue with my Mac 10.6.5, Windows XP and Windows Vista via GigE LAN. If you guys can send in the system logs, it may give us some clue here.

Logs sent as requested.

Regards,
Ian.

[tenortim]

Jedi Knight wrote:
I wasn't able to reproduce the issue with my Mac 10.6.5, Windows XP and Windows Vista via GigE LAN. If you guys can send in the system logs, it may give us some clue here.

Hi,
I already checked the logs and they are silent. Even trying to bump the smb.conf log level didn't yield much. So far, I have managed to get strace onto the box (not trivial since the 64-bit and 32-bit versions are obnoxiously glommed into the same .deb), but it doesn't seem to work exactly correctly wrt the "-f" follow flag (it doesn't follow the children), so I was having to manually attach and trace the children. What I thought I saw during the enumeration were attempts to connect to two addresses that are not active (or even valid for my home subnet) viz something like 10.1.1.6 and 10.1.1.7, which eventually time out. I'm starting to wonder if there's some stale information in a tdb file somewhere.

Anyway, it seems the slow enumeration issue isn't the same problem as the inability to connect from a Linux cifsfs client. In the later case, as documented elsewhere on the forums, if you simply ssh in and restart the Samba, the problem goes away.

I'll work on the debugging again in a few days. Currently busy porting stuff from 2.6.18 to 2.6.32 (fun).

Oh, and I think the Mac issue is yet a third problem. I have no performance problems from either Windows or Linux *once* I am connected, but enumeration is dog-slow, and Linux cannot connect unless I restart Samba after the NV is rebooted.

[Jedi_Knight]

Ian,

The only thing I saw from your system log were TCP Retransmit and Samba restart. I've forward your log to OS and Network Engineer for review as well. For now, I am not able to reproduce the slow broswing issues here.

[IanSav]

Hi Jedi Knight,

Jedi Knight wrote:
The only thing I saw from your system log were TCP Retransmit and Samba restart. I've forward your log to OS and Network Engineer for review as well. For now, I am not able to reproduce the slow broswing issues here.

If you want to see the problem in action I could probably give you a VNC connection to watch a PC take ages to make the initial network connection. I could probably also give you a Slingbox viewer link to watch my PVR fail to discover the ReadyNAS DUO that has been updated.

Regards,
Ian.

[jeremydo]

fwiw, I have tried disabling the smb service (and the http service) and just enabled afp. result: it's even slower.
my nv+ is now so slow, my browser gives me "this page is unresponsive" errors when using the admin ui.
rebooting the nv+ via the web ui does not work - I have to use the button on the front of the box to shut down/restart.
interestingly, even after disabling the smb service (and rebooting the nas), the smb service is still advertised in bonjour (_smb._tcp) - as is the http service (which I also disabled).

Is there a way to revert to 4.1.6 ?

[arsenicrun]

If my Duo's CIFS shares have been recently (within 15-30ish minutes, I'd guess) viewed in Windows, the share will pop up instantaneously, but other than that it requires the 30 to 45 seconds of patience each time to show me the contents. So perhaps unplugging and replugging the client computer into the network might help to reproduce the issue?

Regardless, is it possible or safe to downgrade to 4.1.6? I don't want to risk corrupting the firmware.

[Jedi_Knight]

jeremydo wrote:
Which system logs ? for the client or the server ? I am not able to ssh into my server. I have had a small amount of success enabling afp and using that instead of smb, but it is still glacially slow - 90 seconds to do a directory listing. It almost seems like something else might be running in the background that is taking up a lot of cpu. But I can't tell what.

Go to FrontView->Status Page-> you will see the download all system logs link. Download the zip file and email it to me. Attention Jedi Knight with this post thread.

[Jedi_Knight]

arsenicrun wrote:

If my Duo's CIFS shares have been recently (within 15-30ish minutes, I'd guess) viewed in Windows, the share will pop up instantaneously, but other than that it requires the 30 to 45 seconds of patience each time to show me the contents. So perhaps unplugging and replugging the client computer into the network might help to reproduce the issue? Regardless, is it possible or safe to downgrade to 4.1.6? I don't want to risk corrupting the firmware.

Could you send in your system logs?

[Jedi_Knight]

Jeremy:

Thanks for the system log. I am seeing this in your system log as well as Ian' system log.
--
tcp_retransmit: 76098
tcp_retransmit_unrecovered: 1121
--

Is there anyway would any of you guy willing to do the OS reinstall via system reset switch? and also test with direct connect to PC?

I will have one of my guy contact one by one slowly so that we can walk this issue out.