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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
