Browsing directories slow

[ProtoSD]

Deaks,

Sorry, I'm away on extended vacation in a remote location with limited network access. Which posting above did you use the settings from? Post #5 or #7?

I'm not sure if it really matters, I don't see that you're doing anything incorrectly and don't understand why Samba is crashing.

Just to confirm, are you running the x64 version of FreeNAS?

I have seen people with hardware problems (bad or failing disks) have problems with slow transfer speeds. I'm not sure what else to suggest right now. Maybe one of the other guys here has some ideas.

-- Proto

[Deaks2]

Thanks for answering. I used the information in post 7, however, I will try the CIFS settings from post 5 tonight. I am indeed running the x64 version of FreeNAS. I did have one of my disks fail a few weeks ago, but I got a replacement and it reslivered a-ok. Zpool status is good (checked from the CLI). Not to mention that was on my previous 8.04-Multimedia setup and not the new 8.2b4 setup which has a newly created pool.

[paleoN]

Which posting above did you use the settings from? Post #5 or #7?

I actually thought this post was the latest & greatest. Maybe that's not for slow directory browsing though?

As protosd said Samba shouldn't be crashing.

I have seen people with hardware problems (bad or failing disks) have problems with slow transfer speeds.

Case in point. A single disk can/will pull the entire pool down.

I did have one of my disks fail a few weeks ago, but I got a replacement and it reslivered a-ok. Zpool status is good (checked from the CLI).

I'd run some long smart tests against all the disks and see if that turns anything up.


Delete your current tunables, rerun Auto-Tune and leave the vfs.zfs.arc_max & kernel memory tunings alone for now. Have you tried adding the CIFs settings one at a time? I'd start with:

socket options = SO_RCVBUF=131072 SO_SNDBUF=131072

After you set the tunables, e.g.

kern.ipc.maxsockbuf = 16777216
net.inet.tcp.recvbuf_max = 16777216		
net.inet.tcp.sendbuf_max = 16777216

Actually you could drop those down to 131072 first.

Also, I couldn't see any of your screenshots as I won't turn on javascript for dropbox.

[Deaks2]

Extended SMART tests for all 4 disks come up clean. I've figured out that the "max xmit" variable in CIFS causes samba to exit on signal 6.

[paleoN]

What client(s) are you using? What's in the top level of your share?

Extended SMART tests for all 4 disks come up clean. I've figured out that the "max xmit" variable in CIFS causes samba to exit on signal 6.

Leaving it out, any noticeable change?

max xmit (G)

• This option controls the maximum packet size that will be negotiated by Samba. The default is 16644, which matches the behavior of Windows 2000. A value below 2048 is likely to cause problems. You should never need to change this parameter from its default value.
  
• Default: max xmit = 16644

However, browsing my single CIFS share is quite slow, directory listings (especially my 19000+ file MP3 folder) are slow.

I recently read a recommendation, for Samba, to turn off atime for directories with a very large number of files.


Have you tried creating a small test share with only a couple of folders & only half a dozen of files in each?

[Deaks2]

Client is Win7 x64. Zpool is /mnt/tank, CIFS share is a folder called /mnt/tank/CIFS.

The folder that causes the most problems is my music folder with 19k+ files. My movies folder with 229 files comes up just fine.

With the mods from your post and/or the protosd's posts (including the one you linked to). No discernible difference in performance.

Where would I kill atime? Using the Samba conf file?

[paleoN]

Where would I kill atime? Using the Samba conf file?

Deaks2 if you are still looking for this, you turn of atime under ZFS options for the dataset. You can also double check that Win7 isn't trying to index anything on the share. What's the view option you are using for the music folder anyway?

There's another rather hackish Samba performance tweak, but they talk about it with directories with over 100,000 files in it. It shouldn't apply in your case.

[thisisonlyme]

I have the exact same issue.
File transfer with CIFS is remarkably slower then when using FTP. I can live with that.

Browsing directories (containing 10 000 files) with CIFS is giving me a headache.
Browsing the same directories with SSH is ok (10 000 files in one directory, opens within less than a second).
I've tried the hints from paleoN (sysctls, CIFS auxilary parameters, atime). Without any result. (Thanks anyway for your help!)

FreeNAS-8.0.4-RELEASE-p1-x64 (11059), boot from USB-stick, 4 GB RAM, 3TB 7200 RPM disks.
Disks are ok (Long S.M.A.R.T. tests). Gigabit NIC is ok.
FreeNAS reporting (rrdtool graphs via GUI) tells me the system is OK and it is not swapping.

Any help would be appreciated.

This is what I've tried:

socket options = SO_RCVBUF=131072 SO_SNDBUF=131072

kern.ipc.maxsockbuf = 16777216
net.inet.tcp.recvbuf_max = 16777216
net.inet.tcp.sendbuf_max = 16777216

[ProtoSD]

This is what I've tried:

socket options = SO_RCVBUF=131072 SO_SNDBUF=131072

kern.ipc.maxsockbuf = 16777216
net.inet.tcp.recvbuf_max = 16777216
net.inet.tcp.sendbuf_max = 16777216

It seems like you're missing quite a few of the ones I recommended, you can't just mix and match them. Try them all, then remove or adjust them one at a time (some of them work in groups or pairs).

[paleoN]

I've tried the hints from paleoN (sysctls, CIFS auxilary parameters, atime). Without any result. (Thanks anyway for your help!)

Unless you're Deaks2 in disguise I don't remember helping you. What's more the suggestions I made were a starting point as Samba was crashing on him and not a replacement for everything.

It seems like you're missing quite a few of the ones I recommended, you can't just mix and match them. Try them all, then remove or adjust them one at a time (some of them work in groups or pairs).

+1

Another thing to keep in mind is I never had a slow browsing problem whereas protosd did and fixed it with his settings. I haven't done any in-depth CIFs tuning yet either.