Re: How to umount a busy filesystem?

From: Matthias Schniedermeyer
Date: Tue Oct 12 2004 - 03:51:04 EST


On 12.10.2004 01:24, Jon Masters wrote:
> On Mon, 11 Oct 2004 00:00:55 +0200, Olaf Fr??czyk <olaf@xxxxxxxxxxxxx> wrote:
> > On Sun, 2004-10-10 at 23:12, Matthias Schniedermeyer wrote:
> > > On 10.10.2004 22:52, Olaf Fr?czyk wrote:
> > > > Hi,
> > > >
> > > > Why I cannot umount filesystem if it is being accessed?
> > > > I tried MNT_FORCE option but it doesn't work.
> > > >
> > > > Killing all processes that access a filesystem is not an option. They
> > > > should just get an error when accessing filesystem that is umounted.
> > > >
> > > > Any idea how to do it?
> > >
> > > umount -l
> > >
> > > removes the mount in "lazy"-mode, this way the mount-point "vanishes"
>
> > Thank you.
> > But this:
> > 1. Does not let the user to remove the media (eg. cdrom).
> > 2. Does not flush buffers etc. so the media cannot be safely removed
>
> What you want is the kind of proxy Luke Leighton was talking about in
> a recent post to lkml concerning his effort to port FUSE example code
> in to kernelspace. In his model you can replace the underlying
> filesystem because the user processes are only seeing what you present
> through the proxy - so although proxy inodes/superblock/etc. remain
> constant, the underlying filesystem might get swapped around or moved
> someplace else and the proxy has to work out whether to return errors
> or simply block until the backing filesystem is available for use
> again once more.

Hmmm. "Supermount-ng" seems to also be for this type of problem.
(Never tried it myself)

http://supermount-ng.sourceforge.net/




Bis denn

--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/