4.1.7 Slow To Respond To SMB Network Discovery...

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

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.

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

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.

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

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.

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.

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.

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.

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 ?