Re: [Samba] Slow population of Properties in Windows Explorer
- Date: Fri, 7 Apr 2017 08:53:34 -0700
- From: Jeremy Allison via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] Slow population of Properties in Windows Explorer
On Wed, Apr 05, 2017 at 02:21:48PM -0400, Andrew Richards via samba wrote:
> We recently deployed Samba 4.5 on Debian Jessie-derived Linux with kernel v4.5.7 sharing an XFS filesystem.
> We are migrating a large data set from old NetApp filers to the Samba share. While attempting to monitor the progress of the migration, we are observing very slow population of filesystem metadata in the Properties window (specifically the General tab for info like "Size" and "Contains: n Files, n Folders") for top-level directories via Windows Explorer and very slow recursive directory listing on the command line in PowerShell on Windows Server 2k8 and 2k12 clients mounting the share. Much slower than the same clients querying the same top-level directories via the same methods on the data sets' old home on the NetApp.
> "Very slow" means tens of minutes to complete for the Samba share vs tens of seconds for the same operation on the NetApp share.
> smbstatus shows these Windows clients are mounting via SMB2_10 protocol version. The Linux clients available to us to test with are too old to support any protocol greater than SMB 1, so we don't yet know if this behavior is the same on Linux mounts of the same share via the same protocol doing an 'ls -R' of the same directories.
> I've found several topics related to slow browsing of heavily populated directories (over 10,000 files per directory), but that is not the case here. I have not found much with respect to any kind of performance tuning that can be done to improve the feedback of filesystem metadata through Samba to clients. Is this something the vfs_readahead module can help with? Its man page only mentions Windows Vista, but it isn't clear if the issue it addresses remains in newer versions of Windows Explorer.
Can you do any performance tests on the local
filesystem to see if this is due to XFS xattr
performance ? If you're migrating a lot of ACLs
across we will probably hit the xattr code
very hard. NetApp may be reference counting
the ACLs on WAFL.
To unsubscribe from this list go to the following URL and read the