[Samba] - SOLVED - Weird (slow) performance, querying a large 0-byte tree with lots of xattrs (ZFS over smbd)

Peter B. pb+samba at arkthis.com
Fri Feb 6 20:29:36 UTC 2026


I've solved it!

The reason was (very most likely) a bad shutdown of a ZFS pool - which 
caused its cache partition to become corrupt.
Removing-and-readding the cache fixed the smbd 100% CPU slowdown.

Now the runtime is down from 14s to 0.721 seconds, and avg CPU load of 
~40% (HP Gen8 Proliant 4-bay fileserver).

Anyways,
Thanks - and hopefully this may help someone else save some time.


On 03.02.2026 21:40, Peter B. via samba wrote:
> Hi everyone :)
>
> I'm working with medium-to-large scale digitial collections in the 
> GLAM (Galleries Libraries Archives Museums) domain. I'm a sysadmin, 
> and i'm using xattrs increasingly to support my work handling 
> meta+data :D
>
> I've created thin-copy trees of data, annotated by copy exiftool JSON 
> output to xattrs key/value. Each file has 0-byte (as the source 
> payload data is not copied).
>
> This works great for search/browse and other things.
> So I have these "metadata filesystem trees" I'm working with.
>
> BUT:
> **When I index such a tree over Samba, I get a terrible performance 
> and the CPU spikes to 100% on one core.**
>
> For filesystem properties only access (from ZFS on Proxmox PVE 9.1, 
> Debian 13)
>
>
> I don't see anything in the logfiles.
> And zpool has a few KBs of iostats.
>
> I'm grateful for any hints debugging this.
>
> Thank you :)
> Peter
>
>
> Additional information:
> Running the index on an example tree locally (on the fileserver's 
> ZFS), takes ~0.2 seconds, whereas doing the same on a client machine 
> over smbd mount takes 14 seconds (GBit LAN). TAR of that tree has ~1.9 
> MB, so 14s is long IMO?
>
>
>


-- 
ArkThis AV-RD e.U.
AudioVisual Research & Development
www.ArkThis.com

Tel.: +43 660 200 5734
Stein 115
A-8282 Bad Loipersdorf
UID ATU70313939




More information about the samba mailing list