lkml.org 
[lkml]   [2000]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: Umount & quotas


On Tue, 21 Nov 2000, Jan Kara wrote:

> Hello.
>
> After rewrite of umount checks some time ago (just now reading your mail
> I realized I never asked) filesystem doesn't umount when quotas are
> turned on on it - it fails on check (atomic_read(&mnt->mnt_count) > 2)
> in do_umount().
> Is this intended behaviour? If so, we can remove later DQUOT_OFF() call
> and maybe make somewhere a note about changed behaviour otherwise we should fix
> it...

Oh, fsck...
--- fs/super.c Thu Nov 2 22:38:59 2000
+++ fs/super.c.new Tue Nov 21 11:36:05 2000
@@ -1037,13 +1037,13 @@
}

spin_lock(&dcache_lock);
- if (atomic_read(&mnt->mnt_count) > 2) {
- spin_unlock(&dcache_lock);
- mntput(mnt);
- return -EBUSY;
- }

if (mnt->mnt_instances.next != mnt->mnt_instances.prev) {
+ if (atomic_read(&mnt->mnt_count) > 2) {
+ spin_unlock(&dcache_lock);
+ mntput(mnt);
+ return -EBUSY;
+ }
if (sb->s_type->fs_flags & FS_SINGLE)
put_filesystem(sb->s_type);
/* We hold two references, so mntput() is safe */
Not ideal, but not worse than the variant before the fs/super.c rewrite.
And yes, that's what was intended to be there. Said that, removing the
automagical DQUOT_OFF completely looks like a good idea. If there is no
serious reason to keep it in the kernel I would prefer to move it to
userland. We already have to do quota-related stuff if umount(2) fails...

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

\
 
 \ /
  Last update: 2005-03-22 12:47    [W:0.059 / U:0.780 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site