From: "Mario R. Carro" <mcarro@threads-srl.com>
To: linux-kernel@vger.kernel.org
Subject: Re: FUSE fusexmp proxy example solves umount problem!
Date: Wed, 22 Sep 2004 10:15:05 -0300 [thread overview]
Message-ID: <cirtsq$4j5$1@sea.gmane.org> (raw)
In-Reply-To: 20040922004941.GC14303@lkcl.net
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2332 bytes --]
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" <lkcl@lkcl.net> escribió en el mensaje
news:20040922004941.GC14303@lkcl.net...
> 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:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />
>
prev parent reply other threads:[~2004-09-22 13:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-22 0:49 FUSE fusexmp proxy example solves umount problem! Luke Kenneth Casson Leighton
2004-09-22 9:33 ` Arjan van de Ven
2004-09-22 10:29 ` Luke Kenneth Casson Leighton
2004-09-22 11:21 ` Luke Kenneth Casson Leighton
2004-09-22 13:15 ` Mario R. Carro [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='cirtsq$4j5$1@sea.gmane.org' \
--to=mcarro@threads-srl.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox