Hello,
On Wed, Jul 08, 2009 at 09:39:06PM +0200, Carl Fredrik Hammar wrote:
> On Wed, Jul 08, 2009 at 03:41:51PM +0300, Sergiu Ivanov wrote:
> > On Tue, Jul 07, 2009 at 09:50:12PM +0200, Carl Fredrik Hammar wrote:
> > > On Tue, Jul 07, 2009 at 08:55:37PM +0300, Sergiu Ivanov wrote:
> > > > * fsys_set_options: This RPC should be forwarded to the mountee
> > > > completely. unionmount does not have any command line switches that
> > > > would make much sense being altered at run-time.
> > > >
> > > > * fsys_get_options: This RPC should be forwarded to the mountee
> > > > completely. The reasoning is the same as for fsys_set_options.
> > >
> > > This makes sense if we have unionmount in settrans or a stand-alone
> > > translator with only a single mountee, but not with the current
> > > unionfs implementation.
> >
> > Well, the fact that currently unionmount functionality is implemented
> > as additional option of unionfs should not influence the set of
> > use-cases. I mean that if unionmount is mainly about merging the
> > underlying filesystem and the filesystem of the mountee, we don't
> > really need to modify run-time options of unionmount, regardless of
> > the way it works at the moment.
>
> Perhaps I should clarify, I meant that it doesn't make sense to forward
> the RPC completely if implemented in unionfs, since unionfs does have
> run-time options that users might want to fiddle with. That is,
> forwarding should only be done for the --mount option.
antrik said that this suggestion should be fine in a non-proxying
unionmount, but since our unionmount is expected to be very
transparent, the fsys_{get,set}_options should be forwarded
completely.
Regards,
scolobb
