On Tue, 07 Apr 2026 09:18:11 +0200,
Helg <helg-openbsd@gmx.de> wrote:
> 
> Are ffs and ufs so fundamentally different that ufs_readdir can't
> also benefit from this optimisation?
>

Not really so fundomentally different.

The main win from ffs_readdir() here because I stop doing malloc + VOP_READ
into a temporary buffer, and instead parse directory data from filesystem
buffers directly.

A generic ufs_readdir() rewrite can get part of it, the only missed part is
the clustered read which looks like as FFS specific things.

> What's the purpose of the outer loop. Is this to support the readdir
> buffer being larger than a block and enabling readdir to read more
> than one block per call to readdir? ufs_readdir could benefit from
> this too.
> 

ufs_readdir() does one VOP_READ for up to min(count, 64*1024) entries, so
one getdents call can already span multiple directory blocks.

ffs_readdir() reads one buffer at a time with bread() or bread_cluster(),
and it needs the outer loop to preserve ufs_readdir() behavior.

> I suggest to return EIO instead of EINVAL if a name contains '/'.
> I know this is what ufs does but reading getdents(2) this is not a
> documented reason for returning EINVAL.
> 

Change behaviour requires quite large rework here, and I keep my diff
focused by replacing only one function which preserves behaviour.

Same for the clustered read: probably it can be implemented for UFS level,
but it larger work, more fragiel which will be spread across the tree.

Goal of that diff to test it in very hot path and maybe replicate it to the
UFS level partially or fully if it can be done.

-- 
wbr, Kirill