Patchset to add asynchronous open/close to master

[simo]

On Thu, 2012-06-14 at 13:12 +0200, Stefan (metze) Metzmacher wrote:
> >> aio_close_worker() uses 'close' and skips the next SMB_VFS module!
> > 
> > Yes, you're not paying attention. aio_pthread is *NOT* a stackable
> > module. Never has been. It uses pread and pwrite directly. That
> > has been in the tree a long time. This is unavoidable as the VFS
> > is not thread safe. We can only call the raw syscalls from the
> > worker functions. Come on Metze, you should know this !
> 
> Sure, but reading SMB_VFS_NEXT* calls also in the new code is
> confusing!
> Please avoid it or at least add comments.
> 
> >> 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.
> > 
> > Yes.
> 
> Ok, that is fine, but we should call close() not SMB_VFS_NEXT_CLOSE(),
> even if we're not async.

Oh it is not only confusing but really wrong!
If you open directly you are assuming the fd is a *real* fd, but if the
share has otherwise a 'database backed file store' (like s3) then you
are going to get very weird behavior. Even more so if you open with the
database backend and then  try to close() directly.
That can't work.

So if those options are used you must dynamically change all calls on
that VFS layer from transparent to opaque and not pass onto next
anything anymore, nor open/close, nor read/writes, basically nothing.
It must be a full switch of behavior for all VFS calls.

This is one of the reasons this kind of 'minor feature' should not go in
3.6, it has so many side effects it is not even funny.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>