what do people think about a filesystem proxy kernel module?
has anyone heard of such a beast already?
(which can also do xattrs)
fusexmp.c (in file system in userspace package) does stateless
filesystem proxy redirection.
this is a PERFECT solution to the problem of users removing media
from drives without warning. when i say perfect i mean it doesn't
cause kernel hang-ups, it doesn't involve modifications to userspace
programs such as KDE or Gnome, it doesn't involve any extra work
to HAL, nor UDEV.
it just... _works_.
but, doing file system proxying in userspace introduces an additional
and unnecessary level of inefficiency.
i was wondering therefore if anyone had attempted to do filesystem
proxying before.
ta,
l.
--
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love. If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net"> lkcl.net </a> <br />
<a href="mailto:[email protected]"> [email protected] </a> <br />
On Wed, 2004-09-22 at 02:49, Luke Kenneth Casson Leighton wrote:
> what do people think about a filesystem proxy kernel module?
> has anyone heard of such a beast already?
> (which can also do xattrs)
>
> fusexmp.c (in file system in userspace package) does stateless
> filesystem proxy redirection.
>
> this is a PERFECT solution to the problem of users removing media
> from drives without warning.
eh and the 2.6 kernel doesn't deal with it? It really is supposed to
deal with it nicely already...
On Wed, Sep 22, 2004 at 11:33:30AM +0200, Arjan van de Ven wrote:
> On Wed, 2004-09-22 at 02:49, Luke Kenneth Casson Leighton wrote:
> > what do people think about a filesystem proxy kernel module?
> > has anyone heard of such a beast already?
> > (which can also do xattrs)
> >
> > fusexmp.c (in file system in userspace package) does stateless
> > filesystem proxy redirection.
> >
> > this is a PERFECT solution to the problem of users removing media
> > from drives without warning.
>
> eh and the 2.6 kernel doesn't deal with it?
nope.
not in the slightest bit: i wish it did!!!
i'm using 2.6.8 [.1-selinux1 from http://sf.net/projects/selinux]
> It really is supposed to
> deal with it nicely already...
please tell me how i enable such functionality!
i remove a usb media, HAL does a umount -lf, konqueror still has
directory handles open (see report i sent earlier with the little
program opendir.c which duplicates what konqueror does), then HAL
does an ioctl("/dev/sdc1", Block_Re_Read_PARTition) which returns
an error message "Device or Resource Busy".
david (hal developer) considers this to be a serious bug in the
linux kernel because a user action can cause hotplug events to
not be generated.
the above ioctl is supposed to cause a hotplug event that will
allow HAL to remove the volume from its records.
and it can't.
l.
--
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love. If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net"> lkcl.net </a> <br />
<a href="mailto:[email protected]"> [email protected] </a> <br />
On Wed, Sep 22, 2004 at 11:33:30AM +0200, Arjan van de Ven wrote:
> On Wed, 2004-09-22 at 02:49, Luke Kenneth Casson Leighton wrote:
> > what do people think about a filesystem proxy kernel module?
> > has anyone heard of such a beast already?
> > (which can also do xattrs)
> >
> > fusexmp.c (in file system in userspace package) does stateless
> > filesystem proxy redirection.
> >
> > this is a PERFECT solution to the problem of users removing media
> > from drives without warning.
>
> eh and the 2.6 kernel doesn't deal with it? It really is supposed to
> deal with it nicely already...
okay.
the reason that fusexmp works is because it doesn't actually touch the
filesystem except on an operation: there's no state information stored,
no file handles kept open, no directory handles kept open.
an implementation of this same functionality (a filesystem proxy)
in the linux kernel would involve:
- creating proxy inodes
- reconstructing the full path name
d_path(dentry, mnt, full_path, sizeof(full_path));
then prefixing that with the mount point and then issuing a
proxy command.
now, if the solution to this problem in the linux kernel is broken
because someone forgot to deal with opendir() then _great_.
in the meantime...
l.
--
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love. If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net"> lkcl.net </a> <br />
<a href="mailto:[email protected]"> [email protected] </a> <br />
I had exactly the same idea. I've setup an little project on SourceForge
(http://sf.net/projects/rmvfs). It's just a crude proof of concept by now.
I was thinking in cdroms and diskettes, but I suppose that it applies also
to usb sticks. My original motivation was the cdroms and zip disks being
kept locked in the drives.
I wanted to be able to:
- use the media without needing an explicit mount op (as autofs does).
- be able to extract the media at any time, without an explicit umount and
without being blokced by any lagging process.
- Avoid the risk of corruption.
So:
- the rmvfs mountpoint is always mounted, no explicit mount required.
- rmvfs maintains the target drive always unmounted (unless there's an
operation in progress) so it is safe to extract the media at any time.
- And finally, as you say, by virtue of the proxing, you are always free to
extract the media without problems.
It's performance is very bad but for accessing already slow media (diskettes
and zips) it's fine. The added confort of use it's what it counts, I think,
anyway.
Regards,
MRC
--
"Luke Kenneth Casson Leighton" <[email protected]> escribi? en el mensaje
news:[email protected]...
> what do people think about a filesystem proxy kernel module?
> has anyone heard of such a beast already?
> (which can also do xattrs)
>
> fusexmp.c (in file system in userspace package) does stateless
> filesystem proxy redirection.
>
> this is a PERFECT solution to the problem of users removing media
> from drives without warning. when i say perfect i mean it doesn't
> cause kernel hang-ups, it doesn't involve modifications to userspace
> programs such as KDE or Gnome, it doesn't involve any extra work
> to HAL, nor UDEV.
>
> it just... _works_.
>
> but, doing file system proxying in userspace introduces an additional
> and unnecessary level of inefficiency.
>
> i was wondering therefore if anyone had attempted to do filesystem
> proxying before.
>
> ta,
>
> l.
>
> --
> --
> Truth, honesty and respect are rare commodities that all spring from
> the same well: Love. If you love yourself and everyone and everything
> around you, funnily and coincidentally enough, life gets a lot better.
> --
> <a href="http://lkcl.net"> lkcl.net </a> <br />
> <a href="mailto:[email protected]"> [email protected] </a> <br />
>