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?
Please CC me.
Regards,
Olaf Fraczyk
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"
for all programs whose working-dirs aren't "within" that mount-point.
After all files are closed the filesystem is unmounted totally.
You can "reuse" the mount-point immediatly.
iow. If a programs want to open a file with an absolute path (including
the "<path_to_mountpoint>") then it will fail (or see the other
mountpoint). A program whose working dir is "inside" the mountpoint
(e.g. if it was started from a path "inside" the mountpoint) can still
open file if they use relative paths. Also when you have a bash whose
working dir is "inside" the mountpoint, you can still start programs
that can access the files within that mountpoint.
If you have luck then the program(s) can't open new files (or "see" the
new mountpint). But many (maybe most) programs don't have problems with
a lazy-unmounted mountpoint. Personally i have only encountered one
program that (failed/saw the "other"), which was "acroread" (xpdf on the
other side still can open files in a lazy unmounted mountpoint)
Seems this is the best you can do.
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.
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"
> for all programs whose working-dirs aren't "within" that mount-point.
> After all files are closed the filesystem is unmounted totally.
> You can "reuse" the mount-point immediatly.
>
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
even if it were physically possible (eg. cdrom with unlocked tray or
USB-key).
I have read that the MNT_FORCE is currently limited to NFS mounts.
Does somebody have any idea why it is limited?
Or is the functionality planned for other filesystems too?
Regards,
Olaf
On Mon, 11 Oct 2004 00:00:55 +0200, Olaf Frączyk <[email protected]> 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.
Jon.
On 12.10.2004 01:24, Jon Masters wrote:
> On Mon, 11 Oct 2004 00:00:55 +0200, Olaf Fr??czyk <[email protected]> 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.