Some deficiencies with the Samba VFS that I think need to e rectified ...
Jeremy Allison
jra at samba.org
Tue Dec 10 16:09:46 MST 2013
On Tue, Dec 10, 2013 at 02:33:52PM -0800, Richard Sharpe wrote:
> On Tue, Dec 10, 2013 at 1:46 PM, Volker Lendecke
> <Volker.Lendecke at sernet.de> wrote:
> > On Tue, Dec 10, 2013 at 10:39:21AM -0800, Richard Sharpe wrote:
> >> I agree pretty much with these needs. However, one of the things that
> >> is motivating my grumbling is that we are making too many changes to
> >> Samba, which makes life difficult for us down the road.
> >
> > Can you share more of your requirements and the details of
> > what you are doing? In the other mail today you wrote about
> > findings with regards to previous versions. Do your VFS
> > change requests have anything to do with that? I'm asking
> > because maybe someone on this list has good ideas how to
> > meet your requirements. If you need to develop in private,
> > then fine too.
>
> Well, it does and it doesn't.
>
> 1. We want to introduce fake directories for a couple of reasons. One
> of those was to support things like ~snapshot, although that is going
> to go away. A nice way to do this is to bury it in our VFS module but
> it is quite hard. If we had and FSP associated with each dptr (or
> whatever) then we could hang an FSP extension off it so we could keep
> some state.
The fix here is to replace the return from opendir/fdopendir
from an OS-defined opaque DIR *, to an opaque SMB_DIR *, which
can contain whatever the VFS requires. readdir(), seekdir(),
telldir(), rewinndir() then need to be updated.
This only formalizes what VFS modules like CEPH already
do - for example:
static DIR *cephwrap_fdopendir(struct vfs_handle_struct *handle,
struct files_struct *fsp,
const char *mask,
uint32 attributes)
{...
ret = ceph_opendir(handle->data, fsp->fsp_name->base_name, &result);
if (ret < 0) {
result = NULL;
errno = -ret; /* We return result which is NULL in this case */
}
DEBUG(10, ("[CEPH] fdopendir(...) = %d\n", ret));
return (DIR *) result;
}
So it's easy to keep state here, and other VFS modules
already do it.
> 2. We are stitching together directories on different systems
> separated by a WAN and need access to things like ACCESS_MASK and
> SHARE_MODE in functions like SMB_VFS_MKDIR and some others but it is
> not currently available, which constrains us mightily.
There is a really ugly way to solve this in a non-reentrant way.
Ping me for more details (but it's *really* ugly - be warned :-).
> If more information was exposed during most VFS calls like would be easier.
>
> In general I am hoping that we can support interesting things in Samba
> to ensure that others don't do likewise :-)
Heh heh. Puns-r-us :-).
Jeremy.
More information about the samba-technical
mailing list