Patchset to add asynchronous open/close to master
Stefan (metze) Metzmacher
metze at samba.org
Wed Jun 13 03:54:33 MDT 2012
Hi Jeremy,
> So here is something I've been working on for an OEM
> that I've like to get reviewed and pushed into master.
>
> It adds the ability to do asynchronous creates and closes
> to master for both SMB1 and SMB2 clients. This is a *massive*
> (factor of 10x) help in situations where there is a slow(ish)
> clustered filesystem and there is one multithreaded Windows client
> process doing lots and lots of file creates. Yes, horrible
> applications like this exist :-).
>
> Voker was a massive help to me in bouncing the ideas
> off him for this change, and coming up with ways to
> solve the race conditions it might have created (but
> now does not :-).
>
> It's also a model for how we can add more thread-based
> parallelism into the file server without large rewrites.
>
> There are only a few small changes to the core fileserver
> code, most of the new code is inside vfs_aio_pthread.c.
>
> Michael, this is a perfect example of the kind of new
> feature that OEMs want to be able to add to 3.6.next
> without waiting for a full 4.0.x release.
>
> It was actually developed in 3.6.x and forward ported
> to master - and it's a total of only 1352 lines of
> diff (documentation and build system updates included).
>
> I hope this helps understand the kind of thing I'm
> talking about when I mention feature addition to
> 3.6.x, and would be covered nicely by Ira's suggestion.
>
> Anyway - enjoy, and if I don't hear anything back I'll
> start trickling the changes into master over the next
> week or so (it's actually a fairly simple patchset).
It may look simple, but it isn't!
From the manpage "These are per-share parameters", this is wrong!
The usage of openat() let the module skip the next SMB_VFS module!
There's no infrastructure to cancel async opens! I think it can happen
that the client believes the open was canceled, but the file gets created.
find_completed_open() may checks !(opd->flags & O_EXCL), shouldn't
check O_CREATE? as aio_open_fn()
aio_close_worker() uses 'close' and skips the next SMB_VFS module!
There's no infrastructure to defer async close calls,
so the smb layer calls file_free(), which means we return the result to
the client before the close is done.
adding 'uint64_t mid' to files_struct is an incompatible change.
Just checking if (st.st_uid == opd->uid) isn't enough,
the global context might be switched to a force group context.
Instead of extending the usage of the deferred_open_queue,
we should really create a generic infrastructure based on
tevent_req based _send/_recv function pairs.
metze
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120613/b039fae7/attachment.pgp>
More information about the samba-technical
mailing list