[PATCH] copy-chunk fails if src and dst file are on different tcons

Ralph Böhme slow at samba.org
Mon Jul 3 09:19:08 UTC 2017


On Fri, Jun 30, 2017 at 08:07:56PM +0200, Ralph Böhme via samba-technical wrote:
> On Sat, Apr 22, 2017 at 02:36:35PM +0200, Ralph Böhme wrote:
> > On Fri, Apr 21, 2017 at 02:21:41PM -0700, Jeremy Allison wrote:
> > > On Fri, Apr 21, 2017 at 06:39:38PM +0200, Ralph Böhme via samba-technical wrote:
> > > > On Fri, Apr 21, 2017 at 04:52:10PM +0200, Ralph Böhme wrote:
> > > > > On Fri, Apr 21, 2017 at 12:55:55PM +0200, Ralph Böhme via samba-technical wrote:
> > > > > > Hi!
> > > > > > 
> > > > > > As the subject says, this fails against Samba but works against
> > > > > > Windows. Verified against Windows 2016.
> > > > > > 
> > > > > > Attached is a possible fix plus test.
> > > > > > 
> > > > > > Please review & push if happy. Thanks!
> > > > > 
> > > > > please ignore for now. metze raised an issue over private RPC dealing with the
> > > > > VFS handles that we end up using in the send functions.
> > > > 
> > > > metze, maybe we can just do the check at the vfs layer. See attached patch for
> > > > the basic idea. Should be expanded to cover all vfs functions that take a fsp
> > > > and a vfs handle.
> > > > 
> > > > Just fetching and "looking" at an fsp at the smb layer should be possible, it's
> > > > where we start using it where we should check. Or am I still missing something?
> > > 
> > > Just my 2cents. This looks like the right approach but does mean
> > > changing all of the fsp-based VFS calls.
> > 
> > d'oh! Most VFS macros that take an fsp don't take a conn directly anyway, instead
> > the macro pulls the vfs handle out of the fsp (fsp->conn->vfs_handles). Which is
> > exactly what we want.
> > 
> > There are a few VFS macros that don't adhere to this scheme (eg
> > SMB_VFS_GET_ALLOC_SIZE, SMB_VFS_STREAMINFO, SMB_VFS_STRICT_LOCK,
> > SMB_VFS_COPY_CHUNK_SEND), but I guess that's not an purpose and could be fixed.
> > 
> > Thinking more about it, my change would result in VFS calls running with their
> > curdir set to a different tcon then their fsp. We currently rely on doing a
> > chdir to the share root when processing an smb req for a tcon, don't we? This
> > might actually sink my ship. I imagine shadow_copy2 might not be happy when
> > processing a request to read from an fsp that is assodicated with tcon 1 while
> > the curdir is the share root of tcon 2. Hm.
> 
> so attached is a patchset that adds some magic to the relevant VFS functions
> (copy-chunk) that allows them to work across shares -- something that Windows
> supports.
> 
> The basic idea is to associate a token/cookie with an fsp in the VFS module
> function that sees the source fsp (so the resume-key ioctl in case of
> copy-chunk) and then fetch the source fsp from the cookie again later.
> 
> To generalize on this mechanism and to prepare for future support of ODX
> (Windows Offloaded Data Transfer) I'm consolidating the VFS interface on two
> token based VFS function: OFFLOAD_READ and OFFLOAD_WRITE.
> 
> For now I'm essentially renaming COPY_CHUNK adding the additional fsp/cookie
> magic to allow for copied across shares. SMB layer support for ODX is not yet
> implemented. After some research it seems there is some support in the Linux
> kernel already, exposed via ioctl()s, but we'd need some real ODX capable
> hardware to implement this in Samba.

just pushed this to autobuild.

Cheerio!
-slow



More information about the samba-technical mailing list