samba - Oct 2020 - Performance regression of Windows clients?

On 15/10/2020 09:46, Ralph Boehme wrote:
> Am 10/15/20 um 9:30 AM schrieb Giuseppe Lo Presti via samba:
>> Anyone knowing what happened at the time within samba-technical (if it
>> can be disclosed)?
> 
> iirc I tried to look into this offlist with the OP and actually spent
> considerable time back then trying to reproduce the issue, but
couldn't.
> 
> I can't find the whole thread in my mail archives, only some of my
> responses and it seems the whole thing went nowwhere.
> 
> Generally, Windows Explorer in combination with WIndows kernel SMB VFS
> is quite good at not generating excessive SMB traffic, so I'm a bit
> surprised about that pattern you're describing.
Hello Ralph,

Thanks for having had a look.

For the reproducibility, it should be fairly straightforward with a 
Powershell script as posted at the bottom, and either simply strace smbd 
(just count how many accesses are executed per file), or use wireshark 
as it understands the SMB protocol. Then compare this with the same 
actions performed via bash over a CIFS-mounted path.

We ran the tests with a standalone non-clustered samba (AD member, no DC 
functionality), and we used a local folder on the server, nothing else 
(in particular not a networked file system).

I'm posting this for completeness in case anyone has time/interest to 
look into it.

> I don't have the spare time to look into your problem, sorry. If you
> have the options, you may want to consider using dedicated support:
> 
> <https://www.samba.org/samba/support/globalsupport.html>
Thanks for the pointer, we might consider this in the future.

Cheers,
Giuseppe


----


# PowerShell script to touch and remove 100 files
#
# parameter: target directory (which must exist)

param(
     [parameter(Mandatory=$true)]
     [ValidateNotNullOrEmpty()]$path
)

# first touch the files
$duration = Measure-Command { 1..100 | ForEach-Object { New-Item -Path 
$path -Name "test.$_" -ItemType File -Force } }
$touchtime_ms = [math]::Round($duration.TotalMilliseconds)

# then remove them
$duration = Measure-Command {Remove-Item -Path $path\* -Force}
$rmtime_ms = [math]::Round($duration.TotalMilliseconds)

Write-Host "Touch time: $touchtime_ms"
Write-Host "Remove time: $rmtime_ms"

Am 10/15/20 um 11:01 AM schrieb Giuseppe Lo Presti:
> For the reproducibility, it should be fairly straightforward with a
> Powershell script as posted at the bottom, and either simply strace smbd
> (just count how many accesses are executed per file), or use wireshark
> as it understands the SMB protocol. Then compare this with the same
> actions performed via bash over a CIFS-mounted path.
fwiw, be careful using Powershell scripts trying to reproduce Windows
Explorer behaviour as both will behave differently -- sometimes grossly.

-slow

-- 
Ralph Boehme, Samba Team                https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/
GPG-Fingerprint   FAE2C6088A24252051C559E4AA1E9B7126399E46

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20201015/7f226523/signature.sig>

On 15/10/2020 11:15, Ralph Boehme wrote:
> Am 10/15/20 um 11:01 AM schrieb Giuseppe Lo Presti:
>> For the reproducibility, it should be fairly straightforward with a
>> Powershell script as posted at the bottom, and either simply strace
smbd
>> (just count how many accesses are executed per file), or use wireshark
>> as it understands the SMB protocol. Then compare this with the same
>> actions performed via bash over a CIFS-mounted path.
> 
> fwiw, be careful using Powershell scripts trying to reproduce Windows
> Explorer behaviour as both will behave differently -- sometimes grossly.
Thank you for the heads-up.

Indeed I confirm that Windows Explorer behaves differently, in that less 
of those SMB2_FIND_ID_BOTH_DIRECTORY_INFO queries are issued (e.g. on 
delete of many files). Nevertheless, I confirm a large amount of 
metadata-related requests (stat fstatat, listxattr, getxattr) from 
Windows GUIs, which are not present with Linux clients.

Given the state of affairs, I guess we'll have to really make sure we 
can cache a lot more metadata than required, whereas optimizing the 
Windows clients side does not appear to be at all possible.

Cheers,
Giuseppe