> If I understand you correctly then you are proposing that we
> put all registry values belonging to a registry key as
> attributes to a ldb key to avoid the ONELEVEL search.
It's not just to avoid the onelevel search. Putting each value in a
separate record greatly increases the amount of work you have to do
when loading a shares parameters regardless of whether the database
has an indexed onelevel search or not. So its a bad idea whether we
implemented that feature or not.
> From my point of view this is sub-optimal because I would like to
> follow W2k3 and put the share security descriptors as values into
> the registry key lanmanserver\shares\security. If I imagine the
> 5.000-share server which I've come across a couple of months ago
> then finding a security descriptor for a share would have to walk a
> linear list of on average 2.500 security descriptors.
apart from the fact that is is a rather extreme case, there are ways
to make it fast.
For example, you could take advantage of the fact that ldb preserves
order within a record between store and fetch. So if you store the
share SDs in sorted order (maybe alphabetical by share name), then you
could do a O(log n) search for the SD in the record.
Alternatively, you could put the SD for a share in the share record
itself (thus making its lookup very fast), and make the windows style
lanmanserver\shares\security record a set of generated attributes,
using a ldb module. That would give you speed of access in Samba, plus
compatibility with any windows tools that want the existing layout.
I'm sure there are other solutions as well :-)