CIFS indexing slow on small files

[hfromM]

Hello

I am running a CIFS share on my ZFS raid1 array. I am pleased with my network transfer speeds (usually ~80-90 MBps). My system is:

2.2 GHz dual core turion processor
8GB RAM
2x 4TB seagate drives in raid1

When it comes to handling folders with many files like more than 30000 the indexing, i.e. right click on properties in windows 7 to infer the number of files/size of the folder is extremely slow..

I have already added
ea support = no
store dos attributes = no

in the CIFS section, this did not help much. I also upgraded from 4GB to 8GB of RAM, this increased my transfer speeds a bit, but did not help with my problem unfortunately.

Thank you!

 

[anodos]

Hello

I am running a CIFS share on my ZFS raid1 array. I am pleased with my network transfer speeds (usually ~80-90 MBps). My system is:

2.2 GHz dual core turion processor
8GB RAM
2x 4TB seagate drives in raid1

When it comes to handling folders with many files like more than 30000 the indexing, i.e. right click on properties in windows 7 to infer the number of files/size of the folder is extremely slow..

I have already added
ea support = no
store dos attributes = no

in the CIFS section, this did not help much. I also upgraded from 4GB to 8GB of RAM, this increased my transfer speeds a bit, but did not help with my problem unfortunately.

Thank you!

That process is can be slow on Windows servers too, but your hardware is quite old and slow. You essentially are using an antiquated laptop CPU.

 

[cyberjock]

What anados said. Indexing is a pretty intense workload. Considering your hardware I wouldn't expect good performance. That's just par for the course for that type of workload. ;)

 

[hfromM]

But why do I not see any CPU load while indexing?

I might still consider changing to a different server. Currently it is a HP microserver, N54L. Do you have any recommendations under ~300$ for a whole system? It needs at least space for 4 drives.

 

[anodos]

But why do I not see any CPU load while indexing?

I might still consider changing to a different server. Currently it is a HP microserver, N54L. Do you have any recommendations under ~300$ for a whole system? It needs at least space for 4 drives.

Dell T20, but you'll have to add more ECC ram (it only comes with 4GB). I'd also consider improving its cooling. Otherwise at that price-point you're looking at eBay, but you shouldn't get anything older than sandybridge.

It could also be that the 'indexing' is hitting an IOPS bottleneck. In that case you need more vdevs / spindles. Adding a second pair of 4TB drives may help. In this case you'll have 2 mirrors striped (like raid10).

Adding more ram (which you can do with the T20) should also help performance.

 

[Pasquale61]

I may be wrong here, but I've come to accept that no matter how much horsepower you throw at it, the whole right-click properties on a folder with over 30k files will never perform the same on a Windows network share as it does local. Like anodos mentioned, this is true even on a Windows server. You can make it better, but I don't think it will ever be as responsive as local disk in Windows. It's a matter of finding what is acceptable to you. I blame Microsoft for this, as the task you are performing is very I/O chatty (basically inefficient) especially on a network share. At my work, even on the latest high end enterprise servers running Windows 2012, this process is noticeably slower. This is why we go right on the servers if we have to perform tasks like this for any extended period of time.

The other thing to consider is the computer that you are doing this on. If you copy those 30k files to a local folder, and do a right-click properties, is that speed acceptable to you? It may worth checking in case you're running into a client side bottleneck. At least you'll have what is probably a best case baseline and something to aim for.

Did you try right-click, Properties, Customize tab, selecting General Items, and then checking "Also apply this template to all subfolders?" I have read that this is supposed to help, depending on your folder layout. There's another recent thread here titled "Simple trick to improve responsiveness in Windows." Not sure if any of that applies to you...

 

[Norleif]

The task you described is about the worst workload you could ever throw at a NAS.
It is a sequential process that simply can not be parallelized in any reasonable fashion. Look-ahead caching isn't going to help much either.
Each operation typically only needs a few kb of I/O, but the process cannot continue to the next operation until the response is returned.
Performance is much more related to low latency then high bandwidth.
If you examined each element on it's own, you'd see the CPU load would be quite low on both server and client, the average disk queue would be close to zero on the NAS, and the network throughput would be minimal.
This is because all the individual components are spending most of their time waiting for other components in the chain to finish their job, and this chain is much longer when going to a NAS rather then hitting the local file system.

I got 10Gbit link to my FreeNAS but this still takes forever to complete on a dataset that has about 2.6 million files in it.
I found it's quicker to do a ls -lR > files.txt on the FreeNAS console and parse that output instead of waiting for windows explorer to grind through the CIFS share.

 

[hfromM]

So I changed my system...to:

- Dell T20
- Xeon E3-1225 @ 3.2 GHz
- 12 GB RAM
-2 x 4 TB Western Digital WD40EZRX Caviar Green

I don't see any improvements, regarding transfer speeds or the problem described here. I barely ever see any CPU load above 5% because the CPU is so powerful.

I really think about downgrading again to the Microserver N54L, the Xeon CPU seems a waste, or does anybody know what to do with it?

The Windows 7 client computer is sufficiently fast (Quad Core something).

Another issue is that deleting files is really slow at only 100 elements/sec.

 

[Pasquale61]

Another issue is that deleting files is really slow at only 100 elements/sec.

In my "Windows Server" experience, this is pretty normal when doing this on a real Windows Server network share, let alone trying to do this with a FreeNAS CIFS share. (For reasons described above) If you are going to do a mass delete of files, I think you're better off going to the shell (either in console or via SSH) and using the Linux "rm" command. This is MUCH faster than what you're trying to do. Google it if you're not sure how to use it.

 

[anodos]

So I changed my system...to:

- Dell T20
- Xeon E3-1225 @ 3.2 GHz
- 12 GB RAM
-2 x 4 TB Western Digital WD40EZRX Caviar Green

I don't see any improvements, regarding transfer speeds or the problem described here. I barely ever see any CPU load above 5% because the CPU is so powerful.

I really think about downgrading again to the Microserver N54L, the Xeon CPU seems a waste, or does anybody know what to do with it?

The Windows 7 client computer is sufficiently fast (Quad Core something).

Another issue is that deleting files is really slow at only 100 elements/sec.

I just did a quick test with the following setup (closest I could get to mirror yours:

• Xeon processor
• Vista client
• 32GB RAM
• 1 RAIDZ2 vdev

500 files totaling 1.5GB deleted in 5.5 seconds. If you need to move files around, I recommend using robocopy (which takes advantage of server-side copy in smb2) instead of using Explorer.

If needed, you could probably use a 3rd party application to index your samba share (which should speed things up). locate32 used to be nice, but it's no longer maintained. Why do you need to look up the properties of folders? (This is just curiosity as it is something that I rarely do)