No longer accept fs-specific options from command-line?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

No longer accept fs-specific options from command-line?

Nikolaus Rath
Hello,

At the moment, there are two kinds of options that fuse_session() new
and fuse_new() accept: options that should be chosen by the mounting
user, and options that should be chosen by the file system itself.

For example, whether to specify "-o allow_other" is something that only
the mounting user can decide. On the other hand, whether to use "-o
big_writes" is really something that the programmer of the file system
has to decide based on how he implements the file system.

At the moment, FUSE actively encourages to accept even options of the
latter kind from the command line. It seems to me that this is a bad
idea: at best, it confuses the user with a list of options that he can
not actually choose. At worst, it breaks file systems when the user
specifies an option that isn't actually compatible with the file system
implementation.

I am therefore contemplating to clearly separate the different kind of
options in FUSE 3. Options that should be specified by the user would
continue to be accepted by fuse_session_new() and fuse_new(). However,
options that depend on the file system implementation would instead
become variables in struct fuse_lowlevel_ops and struct fuse_operations.

At the moment, I am thinking about moving the following options:

fuse_session_new():

 -o big_writes
 -o max_write
 -o max_readahead
 -o atomic_o_trunc
 -o [no_]auto_inval_data
 -o default_permissions
 -o fsname=NAME
 -o subtype=NAME
 -o large_read
 -o max_read=N
 -o blksize=N
 
fuse_new():

  -o use_ino             let filesystem set inode numbers
  -o readdir_ino         try to fill in d_ino in readdir
  -o nopath              don't supply path if not necessary
  -o intr                allow requests to be interrupted
  -o intr_signal=NUM     signal to send on interrupt
  -o kernel_cache        cache files in kernel
  -o [no]auto_cache      enable caching based on modification times
  -o direct_io           use direct I/O

I am still on the fence with regard to the various *timeout settings.


Does anyone have any comments against or in favor?


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: No longer accept fs-specific options from command-line?

Jean-Pierre André
Hi,

Nikolaus Rath wrote:

> Hello,
>
> At the moment, there are two kinds of options that fuse_session() new
> and fuse_new() accept: options that should be chosen by the mounting
> user, and options that should be chosen by the file system itself.
>
> For example, whether to specify "-o allow_other" is something that only
> the mounting user can decide. On the other hand, whether to use "-o
> big_writes" is really something that the programmer of the file system
> has to decide based on how he implements the file system.

This is not so clear-cut. The option big_writes is neutral
for ntfs-3g. It is not useful in most cases, it is bad in
some situations (writing files to be stored as compressed),
and it is useful to users who want to back up big files on
an external drive.

For such options, the user space file system developer may
want to accept them from the end user, check whether they
fit within some limits and feed them to fuse. This of course
depends on the file system design, but fuse should not come
across.

> At the moment, FUSE actively encourages to accept even options of the
> latter kind from the command line. It seems to me that this is a bad
> idea: at best, it confuses the user with a list of options that he can
> not actually choose. At worst, it breaks file systems when the user
> specifies an option that isn't actually compatible with the file system
> implementation.

It is up to each user space file system to provide a manual,
to reject bad options and issue errors.

> I am therefore contemplating to clearly separate the different kind of
> options in FUSE 3. Options that should be specified by the user would
> continue to be accepted by fuse_session_new() and fuse_new(). However,
> options that depend on the file system implementation would instead
> become variables in struct fuse_lowlevel_ops and struct fuse_operations.

IMHO inserting variables in structures which are the
main interface between the user space file system and
the library will lead to versioning issues which passing
textual options do not have.

> At the moment, I am thinking about moving the following options:
>
> fuse_session_new():
>
>   -o big_writes
>   -o max_write
>   -o max_readahead
>   -o atomic_o_trunc
>   -o [no_]auto_inval_data
>   -o default_permissions
>   -o fsname=NAME
>   -o subtype=NAME
>   -o large_read
>   -o max_read=N
>   -o blksize=N
>
> fuse_new():
>
>    -o use_ino             let filesystem set inode numbers
>    -o readdir_ino         try to fill in d_ino in readdir
>    -o nopath              don't supply path if not necessary
>    -o intr                allow requests to be interrupted
>    -o intr_signal=NUM     signal to send on interrupt
>    -o kernel_cache        cache files in kernel
>    -o [no]auto_cache      enable caching based on modification times
>    -o direct_io           use direct I/O
>
> I am still on the fence with regard to the various *timeout settings.

This is a case where the setting as an option from the
high level is not satisfactory.

Having the attribute cache timeout returnable from the
getattr() and setattr() variants would be useful in some
cases (namely hard links). Could they be returned in a
"struct fileinfo" ?

Jean-Pierre


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: No longer accept fs-specific options from command-line?

Miklos Szeredi
In reply to this post by Nikolaus Rath
On Wed, Oct 5, 2016 at 6:42 AM, Nikolaus Rath <[hidden email]> wrote:

> Hello,
>
> At the moment, there are two kinds of options that fuse_session() new
> and fuse_new() accept: options that should be chosen by the mounting
> user, and options that should be chosen by the file system itself.
>
> For example, whether to specify "-o allow_other" is something that only
> the mounting user can decide. On the other hand, whether to use "-o
> big_writes" is really something that the programmer of the file system
> has to decide based on how he implements the file system.
>
> At the moment, FUSE actively encourages to accept even options of the
> latter kind from the command line. It seems to me that this is a bad
> idea: at best, it confuses the user with a list of options that he can
> not actually choose. At worst, it breaks file systems when the user
> specifies an option that isn't actually compatible with the file system
> implementation.
>
> I am therefore contemplating to clearly separate the different kind of
> options in FUSE 3. Options that should be specified by the user would
> continue to be accepted by fuse_session_new() and fuse_new(). However,
> options that depend on the file system implementation would instead
> become variables in struct fuse_lowlevel_ops and struct fuse_operations.

Most of these can already be negotiated in ->init() through 'struct
fuse_conn_info', so there's no need for additional flags in *_ops, I
think.

It might make sense to remove them from the list of options shown by
"-h" but some can still be useful as a debugging tool to modify some
parameters without having to recompile the filesystem.   So lets just
make these options "hidden" by not being shown in the default help and
have a "debug help" option that shows all such options as well,
indicating that using these might actually break the filesystem.

>
> At the moment, I am thinking about moving the following options:
>
> fuse_session_new():
>
>  -o big_writes

big_writes was basically a backward compat option and should be made
the default for 3.0.  -omax_write gives fine grained control.

>  -o max_write
>  -o max_readahead
>  -o atomic_o_trunc
>  -o [no_]auto_inval_data
>  -o default_permissions
>  -o fsname=NAME
>  -o subtype=NAME
>  -o large_read

large_read has been deprecated for ever basically, so we can remove it in 3.0.


>  -o max_read=N
>  -o blksize=N
>
> fuse_new():
>
>   -o use_ino             let filesystem set inode numbers
>   -o readdir_ino         try to fill in d_ino in readdir
>   -o nopath              don't supply path if not necessary
>   -o intr                allow requests to be interrupted
>   -o intr_signal=NUM     signal to send on interrupt
>   -o kernel_cache        cache files in kernel
>   -o [no]auto_cache      enable caching based on modification times
>   -o direct_io           use direct I/O
>
> I am still on the fence with regard to the various *timeout settings.
>
>
> Does anyone have any comments against or in favor?

Thanks,
Miklos

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: No longer accept fs-specific options from command-line?

Nikolaus Rath
In reply to this post by Jean-Pierre André
On Oct 05 2016, Jean-Pierre André <[hidden email]> wrote:

> Nikolaus Rath wrote:
>> Hello,
>>
>> At the moment, there are two kinds of options that fuse_session() new
>> and fuse_new() accept: options that should be chosen by the mounting
>> user, and options that should be chosen by the file system itself.
>>
>> For example, whether to specify "-o allow_other" is something that only
>> the mounting user can decide. On the other hand, whether to use "-o
>> big_writes" is really something that the programmer of the file system
>> has to decide based on how he implements the file system.
>
> This is not so clear-cut. The option big_writes is neutral
> for ntfs-3g.
[...]

Alright, bad example. How about -o use_ino then? :-)

>> At the moment, FUSE actively encourages to accept even options of the
>> latter kind from the command line. It seems to me that this is a bad
>> idea: at best, it confuses the user with a list of options that he can
>> not actually choose. At worst, it breaks file systems when the user
>> specifies an option that isn't actually compatible with the file system
>> implementation.
>
> It is up to each user space file system to provide a manual,
> to reject bad options and issue errors.

That's certainly true. But a file system that does its own option
parsing (like presumably ntfs-3g does) would not be accepted by this
decision at all - whether it forwards permissible options in struct
fuse_args or some other means doesn't matter.

I'm concerned about the file systems that rely on FUSE to provide all
the boilerplate functionality. The examples and API actively encourage
this use, so I think it's important to design these functions so that
they work best for the majority of use cases. I am thinking about file
systems like sshfs - the --help output is IMO far from useful. Which
fraction of sshfs *users* actually understand all of it?


>> I am therefore contemplating to clearly separate the different kind of
>> options in FUSE 3. Options that should be specified by the user would
>> continue to be accepted by fuse_session_new() and fuse_new(). However,
>> options that depend on the file system implementation would instead
>> become variables in struct fuse_lowlevel_ops and struct fuse_operations.
>
> IMHO inserting variables in structures which are the
> main interface between the user space file system and
> the library will lead to versioning issues which passing
> textual options do not have.

Could you be more specific? New options would be added at the end of the
struct, and thus be backwards-compatible. Note that we're already doing
this (e.g. for flag_nopath in struct fuse_operations - which now makes
me wonder how this interacts with -o nopath...).

>> I am still on the fence with regard to the various *timeout settings.
>
> This is a case where the setting as an option from the high level is
> not satisfactory.

I'm not so sure about that. If you consider any of the various
passthrough file systems, the user may actually want to have control of
these options.

> Having the attribute cache timeout returnable from the
> getattr() and setattr() variants would be useful in some
> cases (namely hard links). Could they be returned in a
> "struct fileinfo" ?

That may be a valuable feature in any case. But I think it'd require API
changes, since e.g. getattr() doesn't currently get a struct fileinfo to
fill. In other words, we'd better implement this very very soon.


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: No longer accept fs-specific options from command-line?

Nikolaus Rath
In reply to this post by Miklos Szeredi
On Oct 05 2016, Miklos Szeredi <[hidden email]> wrote:

> On Wed, Oct 5, 2016 at 6:42 AM, Nikolaus Rath <[hidden email]> wrote:
>> Hello,
>>
>> At the moment, there are two kinds of options that fuse_session() new
>> and fuse_new() accept: options that should be chosen by the mounting
>> user, and options that should be chosen by the file system itself.
>>
>> For example, whether to specify "-o allow_other" is something that only
>> the mounting user can decide. On the other hand, whether to use "-o
>> big_writes" is really something that the programmer of the file system
>> has to decide based on how he implements the file system.
>>
>> At the moment, FUSE actively encourages to accept even options of the
>> latter kind from the command line. It seems to me that this is a bad
>> idea: at best, it confuses the user with a list of options that he can
>> not actually choose. At worst, it breaks file systems when the user
>> specifies an option that isn't actually compatible with the file system
>> implementation.
>>
>> I am therefore contemplating to clearly separate the different kind of
>> options in FUSE 3. Options that should be specified by the user would
>> continue to be accepted by fuse_session_new() and fuse_new(). However,
>> options that depend on the file system implementation would instead
>> become variables in struct fuse_lowlevel_ops and struct fuse_operations.
>
> Most of these can already be negotiated in ->init() through 'struct
> fuse_conn_info', so there's no need for additional flags in *_ops, I
> think.

Oh, good point. I completely missed that in the past.

> It might make sense to remove them from the list of options shown by
> "-h" but some can still be useful as a debugging tool to modify some
> parameters without having to recompile the filesystem.   So lets just
> make these options "hidden" by not being shown in the default help and
> have a "debug help" option that shows all such options as well,
> indicating that using these might actually break the filesystem.

Making the options less discoverable is certainly a good idea no matter
what else we do, so I'll do that right away.

However, I'm still not sure if exposing them at all makes sense. For
them to be useful for debugging without recompiling, they would need to
take precedence over what the file system requests in init(). But as I
understand do_init() in fuse_lowlevel.c, at the moment the precedence
varies (e.g. the file system has the last word on async_read, but is
overwritten on readdirplus).


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: No longer accept fs-specific options from command-line?

Jean-Pierre André
In reply to this post by Nikolaus Rath
Nikolaus Rath wrote:

> On Oct 05 2016, Jean-Pierre André <[hidden email]> wrote:
>> Nikolaus Rath wrote:
>>> Hello,
>>>
>>> At the moment, there are two kinds of options that fuse_session() new
>>> and fuse_new() accept: options that should be chosen by the mounting
>>> user, and options that should be chosen by the file system itself.
>>>
>>> For example, whether to specify "-o allow_other" is something that only
>>> the mounting user can decide. On the other hand, whether to use "-o
>>> big_writes" is really something that the programmer of the file system
>>> has to decide based on how he implements the file system.
>>
>> This is not so clear-cut. The option big_writes is neutral
>> for ntfs-3g.
> [...]
>
> Alright, bad example. How about -o use_ino then? :-)

Ok for me on "use_ino" decided by the developer, but
in order to assign each option to a category, you have
to investigate each application.

[...]

>>> I am therefore contemplating to clearly separate the different kind of
>>> options in FUSE 3. Options that should be specified by the user would
>>> continue to be accepted by fuse_session_new() and fuse_new(). However,
>>> options that depend on the file system implementation would instead
>>> become variables in struct fuse_lowlevel_ops and struct fuse_operations.
>>
>> IMHO inserting variables in structures which are the
>> main interface between the user space file system and
>> the library will lead to versioning issues which passing
>> textual options do not have.
>
> Could you be more specific? New options would be added at the end of the
> struct, and thus be backwards-compatible. Note that we're already doing
> this (e.g. for flag_nopath in struct fuse_operations - which now makes
> me wonder how this interacts with -o nopath...).

I was mostly thinking of problems related to mixing
pointers and integers, which may lead to alignment
issues when different compilers are used on each
side... And yes the problem already exists on a flags
word, but I thought you had got rid of it.

>
>>> I am still on the fence with regard to the various *timeout settings.
>>
>> This is a case where the setting as an option from the high level is
>> not satisfactory.
>
> I'm not so sure about that. If you consider any of the various
> passthrough file systems, the user may actually want to have control of
> these options.

What I find not satisfactory is having the setting defined
once for all at mount time.

>> Having the attribute cache timeout returnable from the
>> getattr() and setattr() variants would be useful in some
>> cases (namely hard links). Could they be returned in a
>> "struct fileinfo" ?
>
> That may be a valuable feature in any case. But I think it'd require API
> changes, since e.g. getattr() doesn't currently get a struct fileinfo to
> fill. In other words, we'd better implement this very very soon.

Just note I am suggesting this only to implement workarounds
to weak points in fuse. There may be better ways of achieving
this goal.

Jean-Pierre


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: No longer accept fs-specific options from command-line?

Michael Theall
In reply to this post by Nikolaus Rath
On Wed, 2016-10-05 at 09:01 -0700, Nikolaus Rath wrote:

> On Oct 05 2016, Miklos Szeredi <miklos-sUDqSbJrdHQHWmgEVkV9KA@public.
> gmane.org> wrote:
> >
> > On Wed, Oct 5, 2016 at 6:42 AM, Nikolaus Rath <Nikolaus-BTH8mxji4b0
> > @public.gmane.org> wrote:
> > >
> > > Hello,
> > >
> > > At the moment, there are two kinds of options that fuse_session()
> > > new
> > > and fuse_new() accept: options that should be chosen by the
> > > mounting
> > > user, and options that should be chosen by the file system
> > > itself.
> > >
> > > For example, whether to specify "-o allow_other" is something
> > > that only
> > > the mounting user can decide. On the other hand, whether to use
> > > "-o
> > > big_writes" is really something that the programmer of the file
> > > system
> > > has to decide based on how he implements the file system.
> > >
> > > At the moment, FUSE actively encourages to accept even options of
> > > the
> > > latter kind from the command line. It seems to me that this is a
> > > bad
> > > idea: at best, it confuses the user with a list of options that
> > > he can
> > > not actually choose. At worst, it breaks file systems when the
> > > user
> > > specifies an option that isn't actually compatible with the file
> > > system
> > > implementation.
> > >
> > > I am therefore contemplating to clearly separate the different
> > > kind of
> > > options in FUSE 3. Options that should be specified by the user
> > > would
> > > continue to be accepted by fuse_session_new() and fuse_new().
> > > However,
> > > options that depend on the file system implementation would
> > > instead
> > > become variables in struct fuse_lowlevel_ops and struct
> > > fuse_operations.
> > Most of these can already be negotiated in ->init() through 'struct
> > fuse_conn_info', so there's no need for additional flags in *_ops,
> > I
> > think.
> Oh, good point. I completely missed that in the past. 
>
> >
> > It might make sense to remove them from the list of options shown
> > by
> > "-h" but some can still be useful as a debugging tool to modify
> > some
> > parameters without having to recompile the filesystem.   So lets
> > just
> > make these options "hidden" by not being shown in the default help
> > and
> > have a "debug help" option that shows all such options as well,
> > indicating that using these might actually break the filesystem.
> Making the options less discoverable is certainly a good idea no
> matter
> what else we do, so I'll do that right away.
>
> However, I'm still not sure if exposing them at all makes sense. For
> them to be useful for debugging without recompiling, they would need
> to
> take precedence over what the file system requests in init(). But as
> I
> understand do_init() in fuse_lowlevel.c, at the moment the precedence
> varies (e.g. the file system has the last word on async_read, but is
> overwritten on readdirplus). 
>
>
> Best,
> -Nikolaus

Hi Nikolaus,

Our filesystem has many of its own options. We hard-code some of the
FUSE options (like "subtype"), and we pass-through a selected set of
the others from the user (like "allow_other"). Our "help" output splits
the available options into the ones specific to our filesystem, the
ones specific to FUSE (like "allow_other" and "nonempty"), and the
general kernel options (like "ro/rw" and "[no]exec"). We also
conditionally set some FUSE options, such as "default_permissions" by
default, but not if they use our "acl" option. Some of our options
drive things at runtime; for example, we fill
in fuse_entry_param::attr_timeout with the value from our "attrtimeo"
option. We even have an xattr interface to be able to change some of
these options at runtime!

I don't think you can arbitrarily decide which options are user-driven
or application-driven. It should be up to the application to decide how
to present options to their users, regardless if they are application-
specific, FUSE-specific, or general kernel options.

Regards,
Michael Theall


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: No longer accept fs-specific options from command-line?

Nikolaus Rath
On Oct 05 2016, Michael Theall <[hidden email]> wrote:

> Our filesystem has many of its own options. We hard-code some of the
> FUSE options (like "subtype"), and we pass-through a selected set of
> the others from the user (like "allow_other"). Our "help" output splits
> the available options into the ones specific to our filesystem, the
> ones specific to FUSE (like "allow_other" and "nonempty"), and the
> general kernel options (like "ro/rw" and "[no]exec"). We also
> conditionally set some FUSE options, such as "default_permissions" by
> default, but not if they use our "acl" option. Some of our options
> drive things at runtime; for example, we fill
> in fuse_entry_param::attr_timeout with the value from our "attrtimeo"
> option. We even have an xattr interface to be able to change some of
> these options at runtime!

Well, in that case none of the considered changes would affect you at
all. This is only relevant for file systems that quietly pass all
command line options to fuse_main() or fuse_parse_cmdline().

> I don't think you can arbitrarily decide which options are user-driven
> or application-driven. It should be up to the application to decide
> how to present options to their users, regardless if they are
> application- specific, FUSE-specific, or general kernel options.

Absolutely, but luckily no one is taking that away from you. This is
strictly about making live easier for applications that do not want to
do this work and are instead relying on libfuse to do it for them.


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: No longer accept fs-specific options from command-line?

Nikolaus Rath
In reply to this post by Jean-Pierre André
On Oct 05 2016, Jean-Pierre André <[hidden email]> wrote:

> Nikolaus Rath wrote:
>> On Oct 05 2016, Jean-Pierre André <[hidden email]> wrote:
>>> Nikolaus Rath wrote:
>>>> Hello,
>>>>
>>>> At the moment, there are two kinds of options that fuse_session() new
>>>> and fuse_new() accept: options that should be chosen by the mounting
>>>> user, and options that should be chosen by the file system itself.
>>>>
>>>> For example, whether to specify "-o allow_other" is something that only
>>>> the mounting user can decide. On the other hand, whether to use "-o
>>>> big_writes" is really something that the programmer of the file system
>>>> has to decide based on how he implements the file system.
>>>
>>> This is not so clear-cut. The option big_writes is neutral
>>> for ntfs-3g.
>> [...]
>>
>> Alright, bad example. How about -o use_ino then? :-)
>
> Ok for me on "use_ino" decided by the developer, but in order to
> assign each option to a category, you have to investigate each
> application.

That's the point of this thread -- find out if there is consensus that
some options really belong to the file system developer.

But so far, I think Miklos suggestion is the best: hide the options from
the default help text, and rely on the init() function to set
them. Maybe the latter just has to be promoted a little better.


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: No longer accept fs-specific options from command-line?

Antonio SJ Musumeci

While I understand the preference for consistency I'm not sure why libfuse has parameters parsing at all. It is overstepping it's   responsibilities in being a user land API to the kernel. The internal parts of it for passing to mount... sure but the core behavior options are safest to be provided by the filesystem writer.

Doesn't mean there couldn't be a thorough example by which new users could mimic.


On Oct 5, 2016 6:47 PM, "Nikolaus Rath" <[hidden email]> wrote:
On Oct 05 2016, Jean-Pierre André <[hidden email]> wrote:
> Nikolaus Rath wrote:
>> On Oct 05 2016, Jean-Pierre André <[hidden email]> wrote:
>>> Nikolaus Rath wrote:
>>>> Hello,
>>>>
>>>> At the moment, there are two kinds of options that fuse_session() new
>>>> and fuse_new() accept: options that should be chosen by the mounting
>>>> user, and options that should be chosen by the file system itself.
>>>>
>>>> For example, whether to specify "-o allow_other" is something that only
>>>> the mounting user can decide. On the other hand, whether to use "-o
>>>> big_writes" is really something that the programmer of the file system
>>>> has to decide based on how he implements the file system.
>>>
>>> This is not so clear-cut. The option big_writes is neutral
>>> for ntfs-3g.
>> [...]
>>
>> Alright, bad example. How about -o use_ino then? :-)
>
> Ok for me on "use_ino" decided by the developer, but in order to
> assign each option to a category, you have to investigate each
> application.

That's the point of this thread -- find out if there is consensus that
some options really belong to the file system developer.

But so far, I think Miklos suggestion is the best: hide the options from
the default help text, and rely on the init() function to set
them. Maybe the latter just has to be promoted a little better.


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: No longer accept fs-specific options from command-line?

Antonio SJ Musumeci

That said if it is to assume the roll of argument parser and such then I'd not simply hide the arguments but make them inert unless explicitly enabled by the developer.


On Oct 5, 2016 11:30 PM, "Antonio SJ Musumeci" <[hidden email]> wrote:

While I understand the preference for consistency I'm not sure why libfuse has parameters parsing at all. It is overstepping it's   responsibilities in being a user land API to the kernel. The internal parts of it for passing to mount... sure but the core behavior options are safest to be provided by the filesystem writer.

Doesn't mean there couldn't be a thorough example by which new users could mimic.


On Oct 5, 2016 6:47 PM, "Nikolaus Rath" <[hidden email]> wrote:
On Oct 05 2016, Jean-Pierre André <[hidden email]> wrote:
> Nikolaus Rath wrote:
>> On Oct 05 2016, Jean-Pierre André <[hidden email]> wrote:
>>> Nikolaus Rath wrote:
>>>> Hello,
>>>>
>>>> At the moment, there are two kinds of options that fuse_session() new
>>>> and fuse_new() accept: options that should be chosen by the mounting
>>>> user, and options that should be chosen by the file system itself.
>>>>
>>>> For example, whether to specify "-o allow_other" is something that only
>>>> the mounting user can decide. On the other hand, whether to use "-o
>>>> big_writes" is really something that the programmer of the file system
>>>> has to decide based on how he implements the file system.
>>>
>>> This is not so clear-cut. The option big_writes is neutral
>>> for ntfs-3g.
>> [...]
>>
>> Alright, bad example. How about -o use_ino then? :-)
>
> Ok for me on "use_ino" decided by the developer, but in order to
> assign each option to a category, you have to investigate each
> application.

That's the point of this thread -- find out if there is consensus that
some options really belong to the file system developer.

But so far, I think Miklos suggestion is the best: hide the options from
the default help text, and rely on the init() function to set
them. Maybe the latter just has to be promoted a little better.


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel