Quantcast

[PATCH] shadow_copy2: mount_point is valid only for locally mountable file-system

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH] shadow_copy2: mount_point is valid only for locally mountable file-system

Rajesh Joseph
shadow_copy2 currently assumes that all the underlying file-system are
mountable and
are mounted on samba server. But this may not be true for all cases, e.g.
GlusterFS is
accessed via libgfapi and is not mounted.

This can lead to connection failure if such file-systems are used along
with shadow_copy2.
The attached patch assume "/" as the default mount-point in such cases
instead of failing
the connect.

This may not be a complete fix because shadow_copy2_find_mount_point can
return wrong
mount_point if by coincidence the "connectpath" is actually present in the
local file-system.

I had a brief discussion on this with Michael, and we think that it might
be good if VFS layer
can tell if the underlying file-system is mountable or not.

It would be great to know what others think on this problem.

Thanks & Regards,
Rajesh

0001-shadow_copy2-mount_point-is-valid-only-for-locally-m.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] shadow_copy2: mount_point is valid only for locally mountable file-system

Jeremy Allison
On Fri, Sep 30, 2016 at 01:31:58PM +0530, Rajesh Joseph wrote:

> shadow_copy2 currently assumes that all the underlying file-system are
> mountable and
> are mounted on samba server. But this may not be true for all cases, e.g.
> GlusterFS is
> accessed via libgfapi and is not mounted.
>
> This can lead to connection failure if such file-systems are used along
> with shadow_copy2.
> The attached patch assume "/" as the default mount-point in such cases
> instead of failing
> the connect.
>
> This may not be a complete fix because shadow_copy2_find_mount_point can
> return wrong
> mount_point if by coincidence the "connectpath" is actually present in the
> local file-system.
>
> I had a brief discussion on this with Michael, and we think that it might
> be good if VFS layer
> can tell if the underlying file-system is mountable or not.
>
> It would be great to know what others think on this problem.

Yeah, setting it to "/" can also cause problems here:

2613         } else {
2614                 config->snapshot_basepath = talloc_asprintf(config, "%s/%s",
2615                                 config->mount_point, config->snapdir);
2616                 if (config->snapshot_basepath == NULL) {
2617                         DEBUG(0, ("talloc_asprintf() failed\n"));
2618                         errno = ENOMEM;
2619                         return -1;
2620                 }
2621         }

Let me think some more about what "connectpath" should be in
this case.

We have an existing VFS function SMB_VFS_CONNECTPATH(), maybe
this should be expanded to have a different meaning when
we're dealing with a completely virtual underlying FS.

Jeremy.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] shadow_copy2: mount_point is valid only for locally mountable file-system

Michael Adam-3
On 2016-10-10 at 17:11 -0700, Jeremy Allison wrote:

> On Fri, Sep 30, 2016 at 01:31:58PM +0530, Rajesh Joseph wrote:
> > shadow_copy2 currently assumes that all the underlying file-system are
> > mountable and
> > are mounted on samba server. But this may not be true for all cases, e.g.
> > GlusterFS is
> > accessed via libgfapi and is not mounted.
> >
> > This can lead to connection failure if such file-systems are used along
> > with shadow_copy2.
> > The attached patch assume "/" as the default mount-point in such cases
> > instead of failing
> > the connect.
> >
> > This may not be a complete fix because shadow_copy2_find_mount_point can
> > return wrong
> > mount_point if by coincidence the "connectpath" is actually present in the
> > local file-system.
> >
> > I had a brief discussion on this with Michael, and we think that it might
> > be good if VFS layer
> > can tell if the underlying file-system is mountable or not.
> >
> > It would be great to know what others think on this problem.
>
> Yeah, setting it to "/" can also cause problems here:
>
> 2613         } else {
> 2614                 config->snapshot_basepath = talloc_asprintf(config, "%s/%s",
> 2615                                 config->mount_point, config->snapdir);
> 2616                 if (config->snapshot_basepath == NULL) {
> 2617                         DEBUG(0, ("talloc_asprintf() failed\n"));
> 2618                         errno = ENOMEM;
> 2619                         return -1;
> 2620                 }
> 2621         }
>
> Let me think some more about what "connectpath" should be in
> this case.
>
> We have an existing VFS function SMB_VFS_CONNECTPATH(), maybe
> this should be expanded to have a different meaning when
> we're dealing with a completely virtual underlying FS.
Hm,

the connectpath is already set to the path relative to the
volume by vfs_glusterfs/config. (Starting with "/" for the
volume root.)

The problem Rajesh was pointing out was that the path
of the share might be set to something like
"path = /usr/local" (signifying a subdir of the gluster volume)
which conincides to be a local path too, and might be
a mount point. So the find-mountpoint function would
return this as the mountpoint, which is wrong.
In gluster's case we would always have to end up with "/".
If there was a flag inside the vfs that indicates whether
the filsystem is a local / mounted or mountable filesystem
or not, then shadow_copy2_find_mount_point and possibly
other places could behave accordingly.

But maybe there are better options.
For now we have the config workaround of setting
"shadow:mountpoint = /" if glusterfs vfs-module is used.

Cheers - Michael


signature.asc (169 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] shadow_copy2: mount_point is valid only for locally mountable file-system

Samba - samba-technical mailing list
On 2016-10-21 at 09:53 +0200, Michael Adam wrote:

> On 2016-10-10 at 17:11 -0700, Jeremy Allison wrote:
> > On Fri, Sep 30, 2016 at 01:31:58PM +0530, Rajesh Joseph wrote:
> > > shadow_copy2 currently assumes that all the underlying file-system are
> > > mountable and
> > > are mounted on samba server. But this may not be true for all cases, e.g.
> > > GlusterFS is
> > > accessed via libgfapi and is not mounted.
> > >
> > > This can lead to connection failure if such file-systems are used along
> > > with shadow_copy2.
> > > The attached patch assume "/" as the default mount-point in such cases
> > > instead of failing
> > > the connect.
> > >
> > > This may not be a complete fix because shadow_copy2_find_mount_point can
> > > return wrong
> > > mount_point if by coincidence the "connectpath" is actually present in the
> > > local file-system.
> > >
> > > I had a brief discussion on this with Michael, and we think that it might
> > > be good if VFS layer
> > > can tell if the underlying file-system is mountable or not.
> > >
> > > It would be great to know what others think on this problem.
> >
> > Yeah, setting it to "/" can also cause problems here:
> >
> > 2613         } else {
> > 2614                 config->snapshot_basepath = talloc_asprintf(config, "%s/%s",
> > 2615                                 config->mount_point, config->snapdir);
> > 2616                 if (config->snapshot_basepath == NULL) {
> > 2617                         DEBUG(0, ("talloc_asprintf() failed\n"));
> > 2618                         errno = ENOMEM;
> > 2619                         return -1;
> > 2620                 }
> > 2621         }
> >
> > Let me think some more about what "connectpath" should be in
> > this case.
> >
> > We have an existing VFS function SMB_VFS_CONNECTPATH(), maybe
> > this should be expanded to have a different meaning when
> > we're dealing with a completely virtual underlying FS.
>
> Hm,
>
> the connectpath is already set to the path relative to the
> volume by vfs_glusterfs/config. (Starting with "/" for the
> volume root.)
>
> The problem Rajesh was pointing out was that the path
> of the share might be set to something like
> "path = /usr/local" (signifying a subdir of the gluster volume)
> which conincides to be a local path too, and might be
> a mount point. So the find-mountpoint function would
> return this as the mountpoint, which is wrong.
> In gluster's case we would always have to end up with "/".
> If there was a flag inside the vfs that indicates whether
> the filsystem is a local / mounted or mountable filesystem
> or not, then shadow_copy2_find_mount_point and possibly
> other places could behave accordingly.
Hi Jeremy,

Any results from thinking more about it? :-)

Even though the glusterfs vfs module has a configurative
workaround, I would still like to conceptually adress
this...

Cheers - Michael


> But maybe there are better options.
> For now we have the config workaround of setting
> "shadow:mountpoint = /" if glusterfs vfs-module is used.
>
> Cheers - Michael
>



signature.asc (169 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] shadow_copy2: mount_point is valid only for locally mountable file-system

Samba - samba-technical mailing list
On 2017-04-11 at 12:56 +0200, Michael Adam via samba-technical wrote:

> On 2016-10-21 at 09:53 +0200, Michael Adam wrote:
> > On 2016-10-10 at 17:11 -0700, Jeremy Allison wrote:
> > > On Fri, Sep 30, 2016 at 01:31:58PM +0530, Rajesh Joseph wrote:
> > > > shadow_copy2 currently assumes that all the underlying file-system are
> > > > mountable and
> > > > are mounted on samba server. But this may not be true for all cases, e.g.
> > > > GlusterFS is
> > > > accessed via libgfapi and is not mounted.
> > > >
> > > > This can lead to connection failure if such file-systems are used along
> > > > with shadow_copy2.
> > > > The attached patch assume "/" as the default mount-point in such cases
> > > > instead of failing
> > > > the connect.
> > > >
> > > > This may not be a complete fix because shadow_copy2_find_mount_point can
> > > > return wrong
> > > > mount_point if by coincidence the "connectpath" is actually present in the
> > > > local file-system.
> > > >
> > > > I had a brief discussion on this with Michael, and we think that it might
> > > > be good if VFS layer
> > > > can tell if the underlying file-system is mountable or not.
> > > >
> > > > It would be great to know what others think on this problem.
> > >
> > > Yeah, setting it to "/" can also cause problems here:
> > >
> > > 2613         } else {
> > > 2614                 config->snapshot_basepath = talloc_asprintf(config, "%s/%s",
> > > 2615                                 config->mount_point, config->snapdir);
> > > 2616                 if (config->snapshot_basepath == NULL) {
> > > 2617                         DEBUG(0, ("talloc_asprintf() failed\n"));
> > > 2618                         errno = ENOMEM;
> > > 2619                         return -1;
> > > 2620                 }
> > > 2621         }
> > >
> > > Let me think some more about what "connectpath" should be in
> > > this case.
> > >
> > > We have an existing VFS function SMB_VFS_CONNECTPATH(), maybe
> > > this should be expanded to have a different meaning when
> > > we're dealing with a completely virtual underlying FS.
> >
> > Hm,
> >
> > the connectpath is already set to the path relative to the
> > volume by vfs_glusterfs/config. (Starting with "/" for the
> > volume root.)
> >
> > The problem Rajesh was pointing out was that the path
> > of the share might be set to something like
> > "path = /usr/local" (signifying a subdir of the gluster volume)
> > which conincides to be a local path too, and might be
> > a mount point. So the find-mountpoint function would
> > return this as the mountpoint, which is wrong.
> > In gluster's case we would always have to end up with "/".
> > If there was a flag inside the vfs that indicates whether
> > the filsystem is a local / mounted or mountable filesystem
> > or not, then shadow_copy2_find_mount_point and possibly
> > other places could behave accordingly.
>
> Hi Jeremy,
>
> Any results from thinking more about it? :-)
>
> Even though the glusterfs vfs module has a configurative
> workaround, I would still like to conceptually adress
> this...
Ping. :-)

Cheers - Michael

signature.asc (169 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] shadow_copy2: mount_point is valid only for locally mountable file-system

Samba - samba-technical mailing list
On Wed, Apr 26, 2017 at 06:18:12PM +0200, Michael Adam wrote:

> > > > we're dealing with a completely virtual underlying FS.
> > >
> > > Hm,
> > >
> > > the connectpath is already set to the path relative to the
> > > volume by vfs_glusterfs/config. (Starting with "/" for the
> > > volume root.)
> > >
> > > The problem Rajesh was pointing out was that the path
> > > of the share might be set to something like
> > > "path = /usr/local" (signifying a subdir of the gluster volume)
> > > which conincides to be a local path too, and might be
> > > a mount point. So the find-mountpoint function would
> > > return this as the mountpoint, which is wrong.
> > > In gluster's case we would always have to end up with "/".
> > > If there was a flag inside the vfs that indicates whether
> > > the filsystem is a local / mounted or mountable filesystem
> > > or not, then shadow_copy2_find_mount_point and possibly
> > > other places could behave accordingly.
> >
> > Hi Jeremy,
> >
> > Any results from thinking more about it? :-)
> >
> > Even though the glusterfs vfs module has a configurative
> > workaround, I would still like to conceptually adress
> > this...
>
> Ping. :-)

Got two presentations to write for next week. Catch
me @ SambaXP and we'll talk about it.

Loading...