Re: Forced umount (was lazy umount)

Re: Forced umount (was lazy umount)

[Dan Maas]

> Imagine (common error for me):
>
> cd /cdrom
> kwintv &
> [work]
>
> I now want to umount cdrom. How do I do it? Do you suggest each app
> to have "cd /" menu entry?
> Pavel

No but now that you mention it, it might be a good idea for GUI programs to
chdir("/") by default immediately on startup. (and fork/daemonize so they
don't disappear if you accidentally close the xterms you used to start them)

Regards,
Dan

Re: Forced umount (was lazy umount)

[Mike Fedyk]

On Tue, Sep 18, 2001 at 09:15:24PM -0400, Dan Maas wrote:
> > Imagine (common error for me):
> >
> > cd /cdrom
> > kwintv &
> > [work]
> >
> > I now want to umount cdrom. How do I do it? Do you suggest each app
> > to have "cd /" menu entry?
> > Pavel
> 
> No but now that you mention it, it might be a good idea for GUI programs to
> chdir("/") by default immediately on startup. (and fork/daemonize so they
> don't disappear if you accidentally close the xterms you used to start them)
> 

Just disown it after you bg it ie:

xmms & disown

Re: Forced umount (was lazy umount)

[Andreas Schwab]

Mike Fedyk <mfedyk@matchmail.com> writes:

|> On Tue, Sep 18, 2001 at 09:15:24PM -0400, Dan Maas wrote:
|> > > Imagine (common error for me):
|> > >
|> > > cd /cdrom
|> > > kwintv &
|> > > [work]
|> > >
|> > > I now want to umount cdrom. How do I do it? Do you suggest each app
|> > > to have "cd /" menu entry?
|> > > Pavel
|> > 
|> > No but now that you mention it, it might be a good idea for GUI programs to
|> > chdir("/") by default immediately on startup. (and fork/daemonize so they
|> > don't disappear if you accidentally close the xterms you used to start them)
|> > 
|> 
|> Just disown it after you bg it ie:
|> 
|> xmms & disown

This is not necessary unless you did 'shopt -s huponexit'.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

[PATCH] lazy umount (1/4)

[Alexander Viro]

	Patch below (and 3 incrementals to it) implement lazy-umount.

Some background: right now umount() does the following
	* find vfsmount
	* check if it's busy
	* detach from mountpoint and drop a reference
	* mntput() the sucker and return, letting the garbage collection to
do its job - free vfsmount and possibly deactivate and free superblock.

As the matter of fact, kernel will be quite happy to do the same for busy
vfsmounts - they will simply float around (not attached to anything)
until the become non-busy.  At that point they will be freed, etc.
Situation is analogous to unlinked but still busy files - detaching
the tree as analog of removing a link and deactivation (put_super()) as
analog of finally destroying the file.

There are only two things to take care of -
	a) if we detach a parent we should do it for all children
	b) we should not mount anything on "floating" vfsmounts.
Both are obviously staisfied for current code (presence of children
means that vfsmount is busy and we can't mount on something that
doesn't exist).

NOTE: default behaviour of umount(2) is not changed.  We have a new
flag (MNT_DETACH) that tells umount() to be lazy.  If it is absent -
everything works as usual.

It's _very_ useful in a lot of situations - basically, that's what
umount -f should have been.  E.g. suppose that /usr is kept busy
by something (NFS hard mount/hung process/fs bug/whatever).  Right now
we can't do anything about that - it will keep mountpoint busy.
umount("/usr", MNT_DETACH) will do the following:
	a) detach the damned thing from /usr. Nothing is mounted here
anymore.
	b) umount /usr/local, etc. - no matter what state /usr is in and
how badly it's b0rken.
	c) as soon as that fs becomes not busy it will be deactivated
(put_super(), etc.)
	d) if /usr/local wasn't busy - fine, it gets deactivated
immediately. If it was - no problem, it will be deactivated as soon
as it isn't busy anymore.

Code got a lot of beating here during the last 4 months - it's very
convenient when you are doing fs hacking ;-)  Actually I've got into
a habit of using that instead of normal umount in all cases except
the shutdown scripts - works just fine (for obvious reasons in case
of shutdown non-lazy behaviour is precisely what we want).

It had been in -ac since 2.4.8-ac8 (more than three weeks).  Also no
problems.  Please, apply.  Patch is split into 4 pieces, incremental
to each other.

Part 1/4:
	Killed move_vfsmnt(). change_root() does detach_mnt() and attach_mnt()
by hands.

diff -urN S10-pre9-inode/fs/super.c S10-pre9-move_vfsmnt/fs/super.c
--- S10-pre9-inode/fs/super.c	Fri Sep 14 12:58:45 2001
+++ S10-pre9-move_vfsmnt/fs/super.c	Fri Sep 14 14:02:32 2001
@@ -447,37 +447,6 @@
 	return -ENOENT;
 }
 
-#ifdef CONFIG_BLK_DEV_INITRD
-static void move_vfsmnt(struct vfsmount *mnt,
-			struct nameidata *nd, 
-			const char *dev_name)
-{
-	struct nameidata parent_nd;
-	char *new_devname = NULL;
-
-	if (dev_name) {
-		new_devname = kmalloc(strlen(dev_name)+1, GFP_KERNEL);
-		if (new_devname)
-			strcpy(new_devname, dev_name);
-	}
-
-	spin_lock(&dcache_lock);
-	detach_mnt(mnt, &parent_nd);
-	attach_mnt(mnt, nd);
-
-	if (new_devname) {
-		if (mnt->mnt_devname)
-			kfree(mnt->mnt_devname);
-		mnt->mnt_devname = new_devname;
-	}
-	spin_unlock(&dcache_lock);
-
-	/* put the old stuff */
-	if (parent_nd.mnt != mnt)
-		path_release(&parent_nd);
-}
-#endif
-
 static void kill_super(struct super_block *);
 
 void __mntput(struct vfsmount *mnt)
@@ -1941,8 +1910,13 @@
 {
 	struct vfsmount *old_rootmnt;
 	struct nameidata devfs_nd, nd;
+	struct nameidata parent_nd;
+	char *new_devname = kmalloc(strlen("/dev/root.old")+1, GFP_KERNEL);
 	int error = 0;
 
+	if (new_devname)
+		strcpy(new_devname, "/dev/root.old");
+
 	read_lock(&current->fs->lock);
 	old_rootmnt = mntget(current->fs->rootmnt);
 	read_unlock(&current->fs->lock);
@@ -1959,6 +1933,9 @@
 		} else 
 			path_release(&devfs_nd);
 	}
+	spin_lock(&dcache_lock);
+	detach_mnt(old_rootmnt, &parent_nd);
+	spin_unlock(&dcache_lock);
 	ROOT_DEV = new_root_dev;
 	mount_root();
 #if 1
@@ -1980,9 +1957,18 @@
 		blivet = blkdev_get(ramdisk, FMODE_READ, 0, BDEV_FS);
 		printk(KERN_NOTICE "Trying to unmount old root ... ");
 		if (!blivet) {
-			blivet = do_umount(old_rootmnt, 0);
-			mntput(old_rootmnt);
-			if (!blivet) {
+			spin_lock(&dcache_lock);
+			list_del(&old_rootmnt->mnt_list);
+			if (atomic_read(&old_rootmnt->mnt_count) > 2) {
+				spin_unlock(&dcache_lock);
+				mntput(old_rootmnt);
+				blivet = -EBUSY;
+			} else {
+				spin_unlock(&dcache_lock);
+				mntput(old_rootmnt);
+				if (parent_nd.mnt != old_rootmnt)
+					path_release(&parent_nd);
+				mntput(old_rootmnt);
 				ioctl_by_bdev(ramdisk, BLKFLSBUF, 0);
 				printk("okay\n");
 				error = 0;
@@ -1991,10 +1977,22 @@
 		}
 		if (blivet)
 			printk(KERN_ERR "error %d\n", blivet);
+		kfree(new_devname);
 		return error;
 	}
-	/* FIXME: we should hold i_zombie on nd.dentry */
-	move_vfsmnt(old_rootmnt, &nd, "/dev/root.old");
+
+	spin_lock(&dcache_lock);
+	attach_mnt(old_rootmnt, &nd);
+	if (new_devname) {
+		if (old_rootmnt->mnt_devname)
+			kfree(old_rootmnt->mnt_devname);
+		old_rootmnt->mnt_devname = new_devname;
+	}
+	spin_unlock(&dcache_lock);
+
+	/* put the old stuff */
+	if (parent_nd.mnt != old_rootmnt)
+		path_release(&parent_nd);
 	mntput(old_rootmnt);
 	path_release(&nd);
 	return 0;

Re: [PATCH] lazy umount (1/4)

[Alex Stewart]

Alexander Viro wrote:

> It's _very_ useful in a lot of situations - basically, that's what
> umount -f should have been.


Actually, I personally would still like a 'umount -f' (or 'umount 
--yes-I-know-what-Im-doing-and-I-really-mean-it-f' or whatever) that 
actually works for something other than NFS.  In this age of 
hot-pluggable (and warm-pluggable) storage it's increasingly annoying to 
me that I should have to reboot the whole system to fix an otherwise 
hot-fixable hardware problem just because some processes got stuck in a 
disk-wait state before the problem was detected.

I want an operation that will:

1. Interrupt/Abort any processes disk-waiting on the filesystem
2. Unmount the filesystem, immediately and always.
3. Release any filesystem-related holds on the underlying device.
4. Allow me to mount it again later (when problems are fixed).

Basically, I want a 'kill -KILL' for filesystems.

Now, admittedly, this is only something one would want to do in a last 
resort, but currently when one gets to that point of last resort, linux 
has no tools available for them.  This is one of the areas that I've 
always considered linux (and most unixes) to have a gaping hole in the 
"sysadmin should be able to control their system, not vice-versa" 
philosophy, and really is needed in addition to any nifty tricks with 
"lazy umounting", etc. IMO (though the lazy umount thing is kinda nifty, 
and I can see other uses for it).

Just my $.02..

-alex

Forced umount (was lazy umount)

[Ville Herva]

On Sun, Sep 16, 2001 at 09:37:40AM -0700, you [Alex Stewart] claimed:
> Alexander Viro wrote:
> 
> Actually, I personally would still like a 'umount -f' (or 'umount 
> --yes-I-know-what-Im-doing-and-I-really-mean-it-f' or whatever) that 
> actually works for something other than NFS.  In this age of 
> hot-pluggable (and warm-pluggable) storage it's increasingly annoying to 
> me that I should have to reboot the whole system to fix an otherwise 
> hot-fixable hardware problem just because some processes got stuck in a 
> disk-wait state before the problem was detected.
> 
> I want an operation that will:
> 
> 1. Interrupt/Abort any processes disk-waiting on the filesystem
> 2. Unmount the filesystem, immediately and always.
> 3. Release any filesystem-related holds on the underlying device.
> 4. Allow me to mount it again later (when problems are fixed).
> 
> Basically, I want a 'kill -KILL' for filesystems.

This gets my vote too...

It would be interesting to hear if there are large obstacles that make this
impossible or hard to implement or whether it's just that nobody has coded it
yet.


-- v --

v@iki.fi

Re: Forced umount (was lazy umount)

[Aaron Lehmann]

On Mon, Sep 17, 2001 at 09:57:47AM +0300, Ville Herva wrote:
> > Basically, I want a 'kill -KILL' for filesystems.
> 
> This gets my vote too...

<aol>Me too</aol>

Re: Forced umount (was lazy umount)

[Alexander Viro]

On Mon, 17 Sep 2001, Aaron Lehmann wrote:

> On Mon, Sep 17, 2001 at 09:57:47AM +0300, Ville Herva wrote:
> > > Basically, I want a 'kill -KILL' for filesystems.
> > 
> > This gets my vote too...
> 
> <aol>Me too</aol>


Look at it that way: we have two actions that need to be done upon umount.
	1) detach it from the mountpoint(s)
	2) shut it down

For the latter we need to have no active IO on that fs _and_ nothing
that could initiate such IO.  We can separate #1 and #2, letting fs
shutdown happen when it's no longer busy.  That's what MNT_DETACH
does.

What you are asking for is different - you want fs-wide revoke().
That's all nice and dandy, but it's an independent problem and it
will take a _lot_ of work.  Including work in fs drivers.  It _is_
worth doing, but it's 2.5 stuff (along with normal revoke(2)).

IMNSHO we really should separate the stuff acting on mount tree from
the stuff acting on filesystems.  A lot of confusion comes from the
places where we don't do that - see the "per-mountpoint read-only"
thread couple of weeks ago for other examples.

Re: Forced umount (was lazy umount)

[Matthias Andree]

On Mon, 17 Sep 2001, Alexander Viro wrote:

> > On Mon, Sep 17, 2001 at 09:57:47AM +0300, Ville Herva wrote:
> > > > Basically, I want a 'kill -KILL' for filesystems.

Me, too, similarly.

> Look at it that way: we have two actions that need to be done upon umount.
> 	1) detach it from the mountpoint(s)
> 	2) shut it down
> 
> For the latter we need to have no active IO on that fs _and_ nothing
> that could initiate such IO.  We can separate #1 and #2, letting fs
> shutdown happen when it's no longer busy.  That's what MNT_DETACH
> does.
> 
> What you are asking for is different - you want fs-wide revoke().
> That's all nice and dandy, but it's an independent problem and it
> will take a _lot_ of work.  Including work in fs drivers.  It _is_
> worth doing, but it's 2.5 stuff (along with normal revoke(2)).

Well, I think there's another way, not sure if that's feasible, but it
looks so:

You say "no active IO and nothing that initiates that". So add a
MNT_KILLBUSY flag that sends SIGKILL to all process that have resources
on the file system and wake them from "D" state. That way, processes
holding resources will be nuked right away, and the kernel can let go of
the file system.

Possibly needed: Patch other parts of the kernel to allow SIGKILL to
kill a process in 'D' state, interrupting its operations.

FreeBSD can do umount -f for anything except /, not sure how it
implements that, never looked at the source. unmount(2) says "Active
special devices continue to work, but any further accesses to any other
active files result in errors even if the filesystem is later
remounted."

That'd be ok for me, it'd be some sort of a stale local file handle for
the processes that got their filesystem pulled from beneath their feet,
and it's probably the only way to prevent corruption. 

Newly connected processes after a mount should be unaffected by all this
and behave as though the file system had never been (lazily or forcibly)
unmounted before.

However, thanks for the first step in the right way.

-- 
Matthias Andree

"Those who give up essential liberties for temporary safety deserve
neither liberty nor safety." - Benjamin Franklin

Re: Forced umount (was lazy umount)

[Tigran Aivazian]

On Mon, 17 Sep 2001, Matthias Andree wrote:

> On Mon, 17 Sep 2001, Alexander Viro wrote:
> 
> > > On Mon, Sep 17, 2001 at 09:57:47AM +0300, Ville Herva wrote:
> > > > > Basically, I want a 'kill -KILL' for filesystems.
> 
> Me, too, similarly.
> 

Hi,

The forced umount patch has been available for ages and the latest version
can be downloaded from:

http://www.moses.uklinux.net/patches/forced-umount-2.4.9.patch

If there are any issues with it please let me know.

Regards,
Tigran

Re: Forced umount (was lazy umount)

[Alex Stewart]

Tigran Aivazian wrote:

> The forced umount patch has been available for ages and the latest version
> can be downloaded from:
> 
> http://www.moses.uklinux.net/patches/forced-umount-2.4.9.patch
> 
> If there are any issues with it please let me know.


Admittedly, I haven't tried it yet, but the one thing I can see that 
looks like an issue in the context of my original request is that if a 
filesystem's underlying device is having IO problems (bad hardware, 
etc), a forced umount using this patch will potentially also lock up (in 
a D state) trying to close up everything cleanly before unmounting it, 
contributing to the problem instead of fixing it.

I certainly understand (and tend to agree with) Alexander Viro's opinion 
that this is a 2.5 issue (my original post was just to make sure it was 
pointed out that we do still need to work on this), mainly with the 
following reasoning:

I see no reason why a properly functioning system should ever need to 
truly force a umount.  Under normal conditions, if one really needs to 
do an emergency umount, it should be possible to use fuser/kill/etc to 
clean up any processes using the filesystem from userland and then 
perform a normal umount to cleanly unmount the filesystem in question 
(or, with lazy umount, this could conceivably even be done in the 
reverse order).  The only reason for really-I-mean-it-forcing a umount 
is if there is some problem which has caused one or more processes to 
get permanently stuck in a state where they can't be killed (i.e. D 
state), and thus can't release their hold on the filesystem.  Ignoring 
NFS for the moment, assuming that the block device drivers are written 
correctly, there should be no way for anything to get stuck in disk-wait 
for an extended period of time unless there is an actual physical 
hardware problem preventing IO (I believe.. correct me if I'm wrong).

If there is a physical failure preventing IO to the underlying device, 
then it is very likely that any attempts made by the umount call to read 
from or write to the device will also block (unless there are some 
special hooks into the block device drivers to avoid this, which I 
assume there aren't).  Therefore, if a forced umount is actually 
required, it must not attempt to do any IO to the filesystem in question 
either, and must instead just tear down the kernel's structures 
associated with it, leaving the filesystem dirty on the disk, possibly 
losing data in the process.  This is why I had said in my first message 
that this should really only be a very last resort.

Now, a version of this patch which didn't attempt to actually do any IO 
on the device and modified umount (and presumably the various fs 
drivers) so it doesn't do any flushing, fs structure cleanup, etc, might 
be able to adequately do this, but given the degree of unchartedness in 
this territory, I can certainly sympathize with not wanting to put it 
into 2.4.

That's not to say that what the forced umount patch does isn't kinda 
nifty and convenient, and I would like to see this sort of functionality 
too, but it still doesn't really address the problem I was bringing up..

-alex

Re: Forced umount (was lazy umount)

[Xavier Bestel]

le mar 18-09-2001 at 01:21 Alex Stewart a écrit :
[...]
> I see no reason why a properly functioning system should ever need to 
> truly force a umount.  Under normal conditions, if one really needs to 
> do an emergency umount, it should be possible to use fuser/kill/etc to 
> clean up any processes using the filesystem from userland and then 
> perform a normal umount to cleanly unmount the filesystem in question 
> (or, with lazy umount, this could conceivably even be done in the 
> reverse order).  The only reason for really-I-mean-it-forcing a umount 
> is if there is some problem which has caused one or more processes to 
> get permanently stuck in a state where they can't be killed (i.e. D 
> state), and thus can't release their hold on the filesystem.

Imagine you have a cdrom mounted with process reading it. You may want
to eject this cdrom without killing all processes, but just make them
know that there's an error somewhere, go read something else.
So it won't kill your shells, Nautilus/Konqueror, etc.

         Xav

Re: Forced umount (was lazy umount)

[Alex Stewart]

Xavier Bestel wrote:

> le mar 18-09-2001 at 01:21 Alex Stewart a écrit :
> [...]
> 
>>I see no reason why a properly functioning system should ever need to 
>>truly force a umount.  Under normal conditions, if one really needs to 
>>do an emergency umount, it should be possible to use fuser/kill/etc to 
>>clean up any processes using the filesystem from userland and then 
>>perform a normal umount to cleanly unmount the filesystem in question 
[...]

> 
> Imagine you have a cdrom mounted with process reading it. You may want
> to eject this cdrom without killing all processes, but just make them
> know that there's an error somewhere, go read something else.
> So it won't kill your shells, Nautilus/Konqueror, etc.


Ok, I should have made my terms more clear.  I see no reason why a 
properly functioning system should *need* to force a umount.  There's a 
difference between "need" and "want".  What you're talking about is a 
convenience (and I admitted that the patch would make some things more 
convenient), but not a necessity.  With decently written software you 
should be able to simply go to the relevant programs and tell them to 
stop using the filesystem before you unmount it.  All this does is make 
that process a little less tedious.

My point was that I agree that the proposed patch is nice, and I'd like 
to see something like it included, but considering it's primarily a 
convenience rather than addressing something you can't do other ways, I 
think it can probably wait until 2.5 at this point (at least assuming 
2.6 doesn't take as long to get out the door as 2.4 did).  As far as 
fixing the real problem I was bringing up originally (which the patch 
doesn't do), I also think it'll require a large enough change that 
although I'd like to see it sooner, I can understand holding off until 2.5.

-alex

Re: Forced umount (was lazy umount)

[Pavel Machek]

Hi!

> >>I see no reason why a properly functioning system should ever need to 
> >>truly force a umount.  Under normal conditions, if one really needs to 
> >>do an emergency umount, it should be possible to use fuser/kill/etc to 
> >>clean up any processes using the filesystem from userland and then 
> >>perform a normal umount to cleanly unmount the filesystem in question 
> [...]
> 
> > 
> > Imagine you have a cdrom mounted with process reading it. You may want
> > to eject this cdrom without killing all processes, but just make them
> > know that there's an error somewhere, go read something else.
> > So it won't kill your shells, Nautilus/Konqueror, etc.
> 
> 
> Ok, I should have made my terms more clear.  I see no reason why a 
> properly functioning system should *need* to force a umount.  There's a 
> difference between "need" and "want".  What you're talking about is a 
> convenience (and I admitted that the patch would make some things more 
> convenient), but not a necessity.  With decently written software you 
> should be able to simply go to the relevant programs and tell them to 
> stop using the filesystem before you unmount it.  All this does is make 
> that process a little less tedious.

...so... it means that my kwintv (tv-in window) application should
have menu option to chdir somewhere else?

Imagine (common error for me):

cd /cdrom
kwintv &
[work]

I now want to umount cdrom. How do I do it? Do you suggest each app
to have "cd /" menu entry?
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: Forced umount (was lazy umount)

[Xavier Bestel]

Alexander Viro wrote:

> I want an operation that will:
> 
> 1. Interrupt/Abort any processes disk-waiting on the filesystem

Why ? Can't you just return -EBADHANDLE, -E(NX)IO or something similar ?
Aborting should be reserved to mmap()ing processes.

       Xav

Re: Forced umount (was lazy umount)

[Alexander Viro]

On 17 Sep 2001, Xavier Bestel wrote:

> Alexander Viro wrote:

No, I hadn't.  Watch the attributions.

> > I want an operation that will:
> > 
> > 1. Interrupt/Abort any processes disk-waiting on the filesystem
> 
> Why ? Can't you just return -EBADHANDLE, -E(NX)IO or something similar ?
> Aborting should be reserved to mmap()ing processes.