[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