Why does this NOT do what is should be doing, i.e. umount no matter what?
Sometimes I get
umount2 : Stale NFS file handle
umount : machine/path: Illegal seek
and it does not umount it.
What part of
-f "Force unmount (in case of unreachable NFS system)" (umount man page)
does linux not understand?
shouldn't umount -f umount no matter what?
Andy
P? ty , 08/06/2004 klokka 11:54, skreiv Andy:
> Why does this NOT do what is should be doing, i.e. umount no matter what?
>
> Sometimes I get
>
> umount2 : Stale NFS file handle
> umount : machine/path: Illegal seek
>
> and it does not umount it.
>
> What part of
> -f "Force unmount (in case of unreachable NFS system)" (umount man page)
>
> does linux not understand?
Works for me...
On Tue, 8 Jun 2004, Trond Myklebust wrote:
> P? ty , 08/06/2004 klokka 11:54, skreiv Andy:
> > Why does this NOT do what is should be doing, i.e. umount no matter what?
> >
> > Sometimes I get
> >
> > umount2 : Stale NFS file handle
> > umount : machine/path: Illegal seek
> >
> > and it does not umount it.
> >
> > What part of
> > -f "Force unmount (in case of unreachable NFS system)" (umount man page)
> >
> > does linux not understand?
>
> Works for me...
And doesn't always work unconditionaly on other OSes either.
So maybe that's life.
Ian
On Tue, 2004-06-08 at 08:59, Trond Myklebust wrote:
> På ty , 08/06/2004 klokka 11:54, skreiv Andy:
> > Why does this NOT do what is should be doing, i.e. umount no matter what?
> >
> > Sometimes I get
> >
> > umount2 : Stale NFS file handle
> > umount : machine/path: Illegal seek
> >
> > and it does not umount it.
> >
> > What part of
> > -f "Force unmount (in case of unreachable NFS system)" (umount man page)
> >
> > does linux not understand?
>
> Works for me...
>
This works for me on 2.6.7 as well. However, I would get EBUSY back
if processes were hung doing nfs operations to the downed server.
The processes would get unstuck and get EIO, but the umount would
still fail. Doing a 2nd umount -f with no processes waiting for
the server would succeed. This patch retries force umounts in
the kernel an extra time after giving them time to wake up and
get out of the kernel. It doesn't seem quite right to fail
a bunch of nfs operations and leave the file system mounted.
Daniel
diff -urp linux-2.6.7.orig/fs/namespace.c linux-2.6.7/fs/namespace.c
--- linux-2.6.7.orig/fs/namespace.c 2004-06-22 16:41:15.000000000 -0700
+++ linux-2.6.7/fs/namespace.c 2004-06-23 16:28:12.986370695 -0700
@@ -363,6 +363,7 @@ static int do_umount(struct vfsmount *mn
{
struct super_block * sb = mnt->mnt_sb;
int retval;
+ int force_retry_count = 1;
retval = security_sb_umount(mnt, flags);
if (retval)
@@ -376,8 +377,11 @@ static int do_umount(struct vfsmount *mn
* might fail to complete on the first run through as other tasks
* must return, and the like. Thats for the mount program to worry
* about for the moment.
+ * Retry FORCE umount to give processes a chance to wakeup
+ * and get out of the file system.
*/
+retry_force_umount:
lock_kernel();
if( (flags&MNT_FORCE) && sb->s_op->umount_begin)
sb->s_op->umount_begin(sb);
@@ -427,6 +431,18 @@ static int do_umount(struct vfsmount *mn
retval = 0;
}
spin_unlock(&vfsmount_lock);
+
+ if (flags & MNT_FORCE && retval && force_retry_count-- > 0) {
+ up_write(¤t->namespace->sem);
+ /*
+ * give processes a chance to wakeup from force umount
+ */
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout(10);
+ goto retry_force_umount;
+
+ }
+
if (retval)
security_sb_umount_busy(mnt);
up_write(¤t->namespace->sem);
On Wed, Jun 23, 2004 at 04:42:55PM -0700, Daniel McNeil wrote:
> This works for me on 2.6.7 as well. However, I would get EBUSY back
> if processes were hung doing nfs operations to the downed server.
> The processes would get unstuck and get EIO, but the umount would
> still fail. Doing a 2nd umount -f with no processes waiting for
> the server would succeed. This patch retries force umounts in
> the kernel an extra time after giving them time to wake up and
> get out of the kernel. It doesn't seem quite right to fail
> a bunch of nfs operations and leave the file system mounted.
Is there any reason to do that in the kernel? What, umount(8) can't do the
same?
On Wed, 2004-06-23 at 16:47, [email protected]
wrote:
> On Wed, Jun 23, 2004 at 04:42:55PM -0700, Daniel McNeil wrote:
> > This works for me on 2.6.7 as well. However, I would get EBUSY back
> > if processes were hung doing nfs operations to the downed server.
> > The processes would get unstuck and get EIO, but the umount would
> > still fail. Doing a 2nd umount -f with no processes waiting for
> > the server would succeed. This patch retries force umounts in
> > the kernel an extra time after giving them time to wake up and
> > get out of the kernel. It doesn't seem quite right to fail
> > a bunch of nfs operations and leave the file system mounted.
>
> Is there any reason to do that in the kernel? What, umount(8) can't do the
> same?
One reason to do it in the kernel is for consistency at the syscall
layer -- before the syscall it was mounted and after it is unmounted.
The umount syscall can return after causing nfs operations to fail
for processes waiting for a down server with the file system still
mounted.
You're right though, having umount(8) retry the force umount from
user-space might be good enough. Ideally, force umount should
always succeed and retrying once inside the kernel doesn't guarantee
that.
Daniel