Best mechanism for filesystem control

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

Best mechanism for filesystem control

Casey Rodarmor
Heyo,

Btrfs, for example, has a command line utility named 'btrfs' that lets
you get information about a btrfs filesystem and perform many
administrative tasks.

What is the best mechanism to use for similarly controlling a FUSE filesystem?

Since a FUSE filesystem is just a userspace program, I know that I can
use any number of ad hoc mechanisms for controlling it, like listening
over a unix domain socket at a known location, or something like that,
but I wonder if there is a FUSE specific way of doing this.

Thanks!

Best,
Casey

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
--
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: Best mechanism for filesystem control

Nikolaus Rath
On May 19 2016, Casey Rodarmor <casey-iTAM7F1aAMNWk0Htik3J/[hidden email]> wrote:
> Heyo,
>
> Btrfs, for example, has a command line utility named 'btrfs' that lets
> you get information about a btrfs filesystem and perform many
> administrative tasks.
>
> What is the best mechanism to use for similarly controlling a FUSE
> filesystem?

Extended attributes.


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.«

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
--
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: Best mechanism for filesystem control

Michael j Theall

My filesystem uses extended attributes for various controls, but they tend to affect simple settings that work well as key-value pairs. If I wanted to do something more complicated I would probably resort to a UNIX socket.

I only have two somewhat complex extended attributes (both read-only), one of which gives you I/O stats (number of bytes written/read and over what interfaces), and the other lists open files. Obviously I have limited these "control" extended attributes are only usable by the mount owner.

Regards,
Michael Theall

Nikolaus Rath <[hidden email]> wrote on 05/20/2016 11:44:21 AM:

> From: Nikolaus Rath <[hidden email]>

> To: [hidden email]
> Date: 05/20/2016 11:45 AM
> Subject: Re: [fuse-devel] Best mechanism for filesystem control
>


> On May 19 2016, Casey Rodarmor <casey-iTAM7F1aAMNWk0Htik3J/
> [hidden email]> wrote:
> > Heyo,
> >
> > Btrfs, for example, has a command line utility named 'btrfs' that lets
> > you get information about a btrfs filesystem and perform many
> > administrative tasks.
> >
> > What is the best mechanism to use for similarly controlling a FUSE
> > filesystem?
>
> Extended attributes.
>
>
> 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.«
>
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> --
> fuse-devel mailing list
> To unsubscribe or subscribe, visit https://lists.sourceforge.net/
> lists/listinfo/fuse-devel


------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
--
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: Best mechanism for filesystem control

Casey Rodarmor
Are extended attributes appropriate for controlling filesystem-wide
properties, as opposed to controlling the properties of individual
files?

For example, if the filesystem supports compression on a per-file
basis, I can see how using extended attributes would be perfect for
selecting which files should be compressed. However, if the filesystem
supports turning compression on and off for the whole filesystem, it
seems like extended attributes would not be appropriate for this.

On Fri, May 20, 2016 at 9:57 AM, Michael j Theall <[hidden email]> wrote:

> My filesystem uses extended attributes for various controls, but they tend
> to affect simple settings that work well as key-value pairs. If I wanted to
> do something more complicated I would probably resort to a UNIX socket.
>
> I only have two somewhat complex extended attributes (both read-only), one
> of which gives you I/O stats (number of bytes written/read and over what
> interfaces), and the other lists open files. Obviously I have limited these
> "control" extended attributes are only usable by the mount owner.
>
> Regards,
> Michael Theall
>
> Nikolaus Rath <[hidden email]> wrote on 05/20/2016 11:44:21 AM:
>
>> From: Nikolaus Rath <[hidden email]>
>> To: [hidden email]
>> Date: 05/20/2016 11:45 AM
>> Subject: Re: [fuse-devel] Best mechanism for filesystem control
>
>
>>
>> On May 19 2016, Casey Rodarmor <casey-iTAM7F1aAMNWk0Htik3J/
>> [hidden email]> wrote:
>> > Heyo,
>> >
>> > Btrfs, for example, has a command line utility named 'btrfs' that lets
>> > you get information about a btrfs filesystem and perform many
>> > administrative tasks.
>> >
>> > What is the best mechanism to use for similarly controlling a FUSE
>> > filesystem?
>>
>> Extended attributes.
>>
>>
>> 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.«

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
--
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: Best mechanism for filesystem control

Nikolaus Rath
On May 20 2016, Casey Rodarmor <[hidden email]> wrote:
> Are extended attributes appropriate for controlling filesystem-wide
> properties, as opposed to controlling the properties of individual
> files?
>
> For example, if the filesystem supports compression on a per-file
> basis, I can see how using extended attributes would be perfect for
> selecting which files should be compressed. However, if the filesystem
> supports turning compression on and off for the whole filesystem, it
> seems like extended attributes would not be appropriate for this.

I would use a special "control" file in the root of the file system and
use that exclusively for communication with the FUSE daemon. This file
would not be included in the readdir() listing, but you'd still be able
to do setxattr/getxattr on it.


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.«

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
--
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: Best mechanism for filesystem control

Michael j Theall
In reply to this post by Casey Rodarmor

In my case, the filesystem-wide "control" extended attributes are only availble on the mounted directory itself. All subfiles and subdirectories do not have these extended attributes. Basically, I only interpret them when the ino=1.

Regards,
Michael Theall

Casey Rodarmor <[hidden email]> wrote on 05/20/2016 01:24:30 PM:

> From: Casey Rodarmor <[hidden email]>

> To: Michael j Theall/Houston/IBM@IBMUS
> Cc: Nikolaus Rath <[hidden email]>, [hidden email]
> Date: 05/20/2016 01:25 PM
> Subject: Re: [fuse-devel] Best mechanism for filesystem control
>


> Are extended attributes appropriate for controlling filesystem-wide
> properties, as opposed to controlling the properties of individual
> files?
>
> For example, if the filesystem supports compression on a per-file
> basis, I can see how using extended attributes would be perfect for
> selecting which files should be compressed. However, if the filesystem
> supports turning compression on and off for the whole filesystem, it
> seems like extended attributes would not be appropriate for this.
>
> On Fri, May 20, 2016 at 9:57 AM, Michael j Theall <[hidden email]> wrote:
> > My filesystem uses extended attributes for various controls, but they tend
> > to affect simple settings that work well as key-value pairs. If I wanted to
> > do something more complicated I would probably resort to a UNIX socket.
> >
> > I only have two somewhat complex extended attributes (both read-only), one
> > of which gives you I/O stats (number of bytes written/read and over what
> > interfaces), and the other lists open files. Obviously I have limited these
> > "control" extended attributes are only usable by the mount owner.
> >
> > Regards,
> > Michael Theall
> >
> > Nikolaus Rath <[hidden email]> wrote on 05/20/2016 11:44:21 AM:
> >
> >> From: Nikolaus Rath <[hidden email]>
> >> To: [hidden email]
> >> Date: 05/20/2016 11:45 AM
> >> Subject: Re: [fuse-devel] Best mechanism for filesystem control
> >
> >
> >>
> >> On May 19 2016, Casey Rodarmor <casey-iTAM7F1aAMNWk0Htik3J/
> >> [hidden email]> wrote:
> >> > Heyo,
> >> >
> >> > Btrfs, for example, has a command line utility named 'btrfs' that lets
> >> > you get information about a btrfs filesystem and perform many
> >> > administrative tasks.
> >> >
> >> > What is the best mechanism to use for similarly controlling a FUSE
> >> > filesystem?
> >>
> >> Extended attributes.
> >>
> >>
> >> 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.«
>


------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
--
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: Best mechanism for filesystem control

Michael j Theall
In reply to this post by Nikolaus Rath

Nikolaus Rath <[hidden email]> wrote on 05/20/2016 01:49:20 PM:

> From: Nikolaus Rath <[hidden email]>

> To: Casey Rodarmor <[hidden email]>
> Cc: Michael j Theall/Houston/IBM@IBMUS, [hidden email]
> Date: 05/20/2016 01:49 PM
> Subject: Re: [fuse-devel] Best mechanism for filesystem control
>


> On May 20 2016, Casey Rodarmor <[hidden email]> wrote:
> > Are extended attributes appropriate for controlling filesystem-wide
> > properties, as opposed to controlling the properties of individual
> > files?
> >
> > For example, if the filesystem supports compression on a per-file
> > basis, I can see how using extended attributes would be perfect for
> > selecting which files should be compressed. However, if the filesystem
> > supports turning compression on and off for the whole filesystem, it
> > seems like extended attributes would not be appropriate for this.
>
> I would use a special "control" file in the root of the file system and
> use that exclusively for communication with the FUSE daemon. This file
> would not be included in the readdir() listing, but you'd still be able
> to do setxattr/getxattr on it.
>

I also considered this but wanted to avoid the problem of there being a file that happened to have the same name as the control file.

Regards,
Michael Theall

>
> 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.«
>


------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
--
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: Best mechanism for filesystem control

Nikolaus Rath
In reply to this post by Nikolaus Rath
On May 20 2016, "Michael j Theall" <[hidden email]> wrote:

> Nikolaus Rath <[hidden email]> wrote on 05/20/2016 01:49:20 PM:
>
>> From: Nikolaus Rath <[hidden email]>
>> To: Casey Rodarmor <[hidden email]>
>> Cc: Michael j Theall/Houston/IBM@IBMUS, [hidden email]
>> Date: 05/20/2016 01:49 PM
>> Subject: Re: [fuse-devel] Best mechanism for filesystem control
>>
>> On May 20 2016, Casey Rodarmor <[hidden email]> wrote:
>> > Are extended attributes appropriate for controlling filesystem-wide
>> > properties, as opposed to controlling the properties of individual
>> > files?
>> >
>> > For example, if the filesystem supports compression on a per-file
>> > basis, I can see how using extended attributes would be perfect for
>> > selecting which files should be compressed. However, if the filesystem
>> > supports turning compression on and off for the whole filesystem, it
>> > seems like extended attributes would not be appropriate for this.
>>
>> I would use a special "control" file in the root of the file system and
>> use that exclusively for communication with the FUSE daemon. This file
>> would not be included in the readdir() listing, but you'd still be able
>> to do setxattr/getxattr on it.
>>
>
> I also considered this but wanted to avoid the problem of there being a
> file that happened to have the same name as the control file.

Given that the filename can be a pretty long arbitrary byte sequence
that only needs to avoid '/' and '\0', I think that's easily avoided
:-).


Actually, does anyone know if setxattr on the mountpoint itself goes to
the FUSE file system, or to the file system of the parent directory?
That might be an even cleaner solution.


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.«

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
--
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: Best mechanism for filesystem control

Michael j Theall

Nikolaus Rath <[hidden email]> wrote on 05/20/2016 02:07:11 PM:

> From: Nikolaus Rath <[hidden email]>

> To: Michael j Theall/Houston/IBM@IBMUS
> Cc: Casey Rodarmor <[hidden email]>, [hidden email]
> Date: 05/20/2016 02:07 PM
> Subject: Re: [fuse-devel] Best mechanism for filesystem control
>


> On May 20 2016, "Michael j Theall" <[hidden email]> wrote:
> > Nikolaus Rath <[hidden email]> wrote on 05/20/2016 01:49:20 PM:
> >
> >> From: Nikolaus Rath <[hidden email]>
> >> To: Casey Rodarmor <[hidden email]>
> >> Cc: Michael j Theall/Houston/IBM@IBMUS, [hidden email]
> >> Date: 05/20/2016 01:49 PM
> >> Subject: Re: [fuse-devel] Best mechanism for filesystem control
> >>
> >> On May 20 2016, Casey Rodarmor <[hidden email]> wrote:
> >> > Are extended attributes appropriate for controlling filesystem-wide
> >> > properties, as opposed to controlling the properties of individual
> >> > files?
> >> >
> >> > For example, if the filesystem supports compression on a per-file
> >> > basis, I can see how using extended attributes would be perfect for
> >> > selecting which files should be compressed. However, if the filesystem
> >> > supports turning compression on and off for the whole filesystem, it
> >> > seems like extended attributes would not be appropriate for this.
> >>
> >> I would use a special "control" file in the root of the file system and
> >> use that exclusively for communication with the FUSE daemon. This file
> >> would not be included in the readdir() listing, but you'd still be able
> >> to do setxattr/getxattr on it.
> >>
> >
> > I also considered this but wanted to avoid the problem of there being a
> > file that happened to have the same name as the control file.
>
> Given that the filename can be a pretty long arbitrary byte sequence
> that only needs to avoid '/' and '\0', I think that's easily avoided
> :-).
>
>
> Actually, does anyone know if setxattr on the mountpoint itself goes to
> the FUSE file system, or to the file system of the parent directory?
> That might be an even cleaner solution.
>
>

Don't know if you saw my other reply to this thread (seems like we replied at the same time), but that is exactly what my filesystem does: use the mount point itself for these "control" extended attributes. If you think about it, setxattr (or any request, really) on the mount point itself *has* to go to the FUSE filesystem. It will come in as ino=FUSE_ROOT_ID (i.e. ino=1). The only way to perform a request on the parent filesystem is if you acquired a handle to that directory entry before the FUSE filesystem was mounted.

Regards,
Michael Theall

> 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.«
>


------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
--
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: Best mechanism for filesystem control

alex.
This discussion has been an interesting read for me, because I would
have cleanly said that a `btrfs`-like tool for administrative purposes
is clearly fuse-fs dependent - so a general suggestion is ill-purposed.
Obviously a filesystem mounting a file like a folder (like mounting
images or truecrypt-style containers) have quite different needs and use
cases than network-filesystems or piped-filesystems etc.

In fact I asked myself the same question for my fs and ended up creating
a git-style program that only boots the fuse-daemon when I type `fs
mount [...]`. This enabled me to program all kinds of administrative
subcommands like `fs defrag` or  `fs create-user`. It works quite
nicely, even if the fs is mounted, as all operations are atomic.

The answers to this question did not suggest anything of this sort, so I
wanted to give a heads up that this is a potential alternative to
xattrs. Of course the extent depends largely on the project at hand.

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
--
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: Best mechanism for filesystem control

Bernd Schubert-7
In reply to this post by Nikolaus Rath
On Friday, May 20, 2016 9:44:21 AM CEST Nikolaus Rath wrote:
> On May 19 2016, Casey Rodarmor <casey-iTAM7F1aAMNWk0Htik3J/
[hidden email]> wrote:

> > Heyo,
> >
> > Btrfs, for example, has a command line utility named 'btrfs' that lets
> > you get information about a btrfs filesystem and perform many
> > administrative tasks.
> >
> > What is the best mechanism to use for similarly controlling a FUSE
> > filesystem?
>
> Extended attributes.
>

I would say ioctls. EAs can be used to store meta information for single files
or directories, ioctls can be used for the whole file system control or non-
posix actions for files/dirs.

Bernd






------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
--
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: Best mechanism for filesystem control

Michael j Theall

Bernd Schubert <[hidden email]> wrote on 05/24/2016 03:56:33 AM:

> From: Bernd Schubert <[hidden email]>

> To: [hidden email]
> Date: 05/24/2016 03:57 AM
> Subject: Re: [fuse-devel] Best mechanism for filesystem control
>


> On Friday, May 20, 2016 9:44:21 AM CEST Nikolaus Rath wrote:
> > On May 19 2016, Casey Rodarmor <casey-iTAM7F1aAMNWk0Htik3J/
> [hidden email]> wrote:
> > > Heyo,
> > >
> > > Btrfs, for example, has a command line utility named 'btrfs' that lets
> > > you get information about a btrfs filesystem and perform many
> > > administrative tasks.
> > >
> > > What is the best mechanism to use for similarly controlling a FUSE
> > > filesystem?
> >
> > Extended attributes.
> >
>
> I would say ioctls. EAs can be used to store meta information for
> single files
> or directories, ioctls can be used for the whole file system control or non-
> posix actions for files/dirs.
>
> Bernd
>
>
>

My filesystem also uses ioctl's but not for filesystem-level controls. The drawback for me is that ioctl's require at least three steps: 1. open a file/directory, 2. issue the ioctl, 3. close the file/directory. The first and third are relatively expensive operations in my filesystem (network-based). By using extended attributes, I can perform actions without ever sending any requests to the backing filesystem.

Regards,
Michael Theall

>
>
>
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> --
> fuse-devel mailing list
> To unsubscribe or subscribe, visit https://lists.sourceforge.net/
> lists/listinfo/fuse-devel
>


------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
--
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: Best mechanism for filesystem control

Nikolaus Rath
In reply to this post by Bernd Schubert-7
On May 24 2016, Bernd Schubert <[hidden email]> wrote:

> On Friday, May 20, 2016 9:44:21 AM CEST Nikolaus Rath wrote:
>> On May 19 2016, Casey Rodarmor <casey-iTAM7F1aAMNWk0Htik3J/
> [hidden email]> wrote:
>> > Heyo,
>> >
>> > Btrfs, for example, has a command line utility named 'btrfs' that lets
>> > you get information about a btrfs filesystem and perform many
>> > administrative tasks.
>> >
>> > What is the best mechanism to use for similarly controlling a FUSE
>> > filesystem?
>>
>> Extended attributes.
>
> I would say ioctls. EAs can be used to store meta information for
> single files or directories, ioctls can be used for the whole file
> system control or non- posix actions for files/dirs.

I don't understand. Just as you set EAs for individual files, you have
to issue ioctls on specific file descriptors (i.e., you have to open a
specific file or directory first). In each case, whether the effect is
local to the file or global to the fs is up to the fuse daemon handling
the request.

However, ioctls have the additional drawback of requiring more
operations (open/ioctl/close) and being of fixed-size.

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.«

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
--
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: Best mechanism for filesystem control

Nikolaus Rath
In reply to this post by alex.
On May 24 2016, "alex." <[hidden email]> wrote:

> This discussion has been an interesting read for me, because I would
> have cleanly said that a `btrfs`-like tool for administrative purposes
> is clearly fuse-fs dependent - so a general suggestion is ill-purposed.
> Obviously a filesystem mounting a file like a folder (like mounting
> images or truecrypt-style containers) have quite different needs and use
> cases than network-filesystems or piped-filesystems etc.
>
> In fact I asked myself the same question for my fs and ended up creating
> a git-style program that only boots the fuse-daemon when I type `fs
> mount [...]`. This enabled me to program all kinds of administrative
> subcommands like `fs defrag` or  `fs create-user`. It works quite
> nicely, even if the fs is mounted, as all operations are atomic.
>
> The answers to this question did not suggest anything of this sort, so I
> wanted to give a heads up that this is a potential alternative to
> xattrs. Of course the extent depends largely on the project at hand.

Actually, I think the answers suggested exactly that sort of
solution. It's just that your `btrfs`-like tool will internally set
extended attributes on the mountpoint to communicate with the file
system.

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.«

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
--
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: Best mechanism for filesystem control

Bernd Schubert-7
In reply to this post by Bernd Schubert-7
On Tuesday, May 24, 2016 10:05:39 AM CEST Michael j Theall wrote:

> Bernd Schubert <[hidden email]> wrote on 05/24/2016 03:56:33
>
> AM:
> > From: Bernd Schubert <[hidden email]>
> > To: [hidden email]
> > Date: 05/24/2016 03:57 AM
> > Subject: Re: [fuse-devel] Best mechanism for filesystem control
> >
> > On Friday, May 20, 2016 9:44:21 AM CEST Nikolaus Rath wrote:
> > > On May 19 2016, Casey Rodarmor <casey-iTAM7F1aAMNWk0Htik3J/
> >
> > [hidden email]> wrote:
> > > > Heyo,
> > > >
> > > > Btrfs, for example, has a command line utility named 'btrfs' that
>
> lets
>
> > > > you get information about a btrfs filesystem and perform many
> > > > administrative tasks.
> > > >
> > > > What is the best mechanism to use for similarly controlling a FUSE
> > > > filesystem?
> > >
> > > Extended attributes.
> >
> > I would say ioctls. EAs can be used to store meta information for
> > single files
> > or directories, ioctls can be used for the whole file system control or
>
> non-
>
> > posix actions for files/dirs.
> >
> > Bernd
>
> My filesystem also uses ioctl's but not for filesystem-level controls. The
> drawback for me is that ioctl's require at least three steps: 1. open a
> file/directory, 2. issue the ioctl, 3. close the file/directory. The first
> and third are relatively expensive operations in my filesystem
> (network-based). By using extended attributes, I can perform actions
> without ever sending any requests to the backing filesystem.

This makes me wonder what you are actually controlling. I would have seen
"file system control" as something like changing the log level, enabling
debugging, etc. For setting actions for lots of files EAs indeed will have the
better performance (although I probably would have added a control socket to
the fuse daemon then).

Bernd

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
--
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: Best mechanism for filesystem control

Michael j Theall

Bernd Schubert <[hidden email]> wrote on 05/25/2016 04:42:10 AM:

> From: Bernd Schubert <[hidden email]>

> To: [hidden email]
> Cc: Michael j Theall/Houston/IBM@IBMUS
> Date: 05/25/2016 04:42 AM
> Subject: Re: [fuse-devel] Best mechanism for filesystem control
>


> On Tuesday, May 24, 2016 10:05:39 AM CEST Michael j Theall wrote:
> > Bernd Schubert <[hidden email]> wrote on 05/24/2016 03:56:33
> >
> > AM:
> > > From: Bernd Schubert <[hidden email]>
> > > To: [hidden email]
> > > Date: 05/24/2016 03:57 AM
> > > Subject: Re: [fuse-devel] Best mechanism for filesystem control
> > >
> > > On Friday, May 20, 2016 9:44:21 AM CEST Nikolaus Rath wrote:
> > > > On May 19 2016, Casey Rodarmor <casey-iTAM7F1aAMNWk0Htik3J/
> > >
> > > [hidden email]> wrote:
> > > > > Heyo,
> > > > >
> > > > > Btrfs, for example, has a command line utility named 'btrfs' that
> >
> > lets
> >
> > > > > you get information about a btrfs filesystem and perform many
> > > > > administrative tasks.
> > > > >
> > > > > What is the best mechanism to use for similarly controlling a FUSE
> > > > > filesystem?
> > > >
> > > > Extended attributes.
> > >
> > > I would say ioctls. EAs can be used to store meta information for
> > > single files
> > > or directories, ioctls can be used for the whole file system control or
> >
> > non-
> >
> > > posix actions for files/dirs.
> > >
> > > Bernd
> >
> > My filesystem also uses ioctl's but not for filesystem-level controls. The
> > drawback for me is that ioctl's require at least three steps: 1. open a
> > file/directory, 2. issue the ioctl, 3. close the file/directory. The first
> > and third are relatively expensive operations in my filesystem
> > (network-based). By using extended attributes, I can perform actions
> > without ever sending any requests to the backing filesystem.
>
> This makes me wonder what you are actually controlling. I would have seen
> "file system control" as something like changing the log level, enabling
> debugging, etc. For setting actions for lots of files EAs indeed
> will have the
> better performance (although I probably would have added a control socket to
> the fuse daemon then).
>
> Bernd
>

My filesystem-level controls (EAs that exist only on the root directory) are mostly changing various log levels. I have two read-only EAs here, one outputs a list of open files, the other outputs statistics, such as network I/O counts and network interfaces used. There are per-file and per-directory EAs that are non-POSIX attributes (ones that don't come from stat(2)), but very few of them "control" the file in any way. Then there are ioctl(2) commands which are truly per-file/directory controls which actually require an open file on the backing filesystem, such as controlling whether the file can be removed from disk once it has been copied to tape, or the ability to undelete a file/directory.

Regards,
Michael Theall

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel