Question(s) about smbd in respect to preadv2

[Milosz Tanski]

I'm at a bit of a cross roads with testing preadv2 using samba and how
samba could benefit from the syscall. I need to better understand the
samba architecture today and where it's going. I spent a few hours
yesterday and today better to understand samba; I also looked at
Jermey's SambaXP 2014 talk. There's a few clarifications I need.

I did some preliminary testing using preadv2 to perform. The first
tests I ran were using the source3 smbd server. And I compared the
sync, pthreadpool and pthreadpool + preadv2. Just a simple rand read
test with one client with a cached data.

The results were that sync was fastest (no surprise there).
Pthreadpool + preadv2 was about 8% slower then sync. Plain old
pthreadpool 26% slower. So not a bad win there. Additionally, it looks
like the vfs_pread_send and vfs_pread_recv have a bit more overhead
over plain old vfs_pread in the code path so it's possible to get that
8% even closer to the sync case.

So far, so good... but what struct me is that I don't really
understand why samba uses the pthreadpool if forks() for each client
connection? Why bother.

>From looking at the code in for source3, source4 and internet readings
(like Jeremy's talk). It looks like there's an ambition to not have a
process per connection model in the future. Am I correct in that
assumption?

Is the hope to have one process with a main (or few) thread handling
the most of the incoming network IO and then a largish threadpool for
performing most of the accentual disk IO work?

That's the kind of use case that preadv2 was conceived for. Otherwise
I'm not sure if it's the right fit and I'm not quite sure what's the
point of the threadpool is.

-- 
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016

p: 646-253-9055
e: milosz at adfin.com