> For what it's worth, ext2 and ext4 have the same problems... Thanks a lot for the first response! I really appreciate it. >> --- linux-2.6.26.2/fs/ext3/super.c.orig 2008-08-18 11:01:02.000000000 +0900 >> +++ linux-2.6.26.2/fs/ext3/super.c 2008-08-18 11:06:29.000000000 +0900 >> @@ -1898,7 +1898,8 @@ static int ext3_fill_super (struct super >> goto failed_mount4; >> } >> >> - ext3_setup_super (sb, es, sb->s_flags & MS_RDONLY); >> + if (ext3_setup_super (sb, es, sb->s_flags & MS_RDONLY)) >> + sb->s_flags |= MS_RDONLY; >> /* >> * akpm: core read_super() calls in here with the superblock locked. >> * That deadlocks, because orphan cleanup needs to lock the >> superblock @@ -2506,8 +2507,8 @@ static int ext3_remount (struct super_bl >> sbi->s_mount_state = le16_to_cpu(es->s_state); >> if ((err = ext3_group_extend(sb, es, >> n_blocks_count))) > One other thing I worry about; we are doing group_extend before we check > the revision. Is that safe? We also still do things like replay the > journal and process orphan inodes before checking the revision. > > Should we even worry about this, or is the revision level never going > to change again, and we can almost just ignore it > > now? (or assume > that for recent kernels, a too-high rev level indicates corruption and > fail the > mount?) > > -Eric I think I need more time to find an appropriate answer, but I'll be keeping busy for a while. Please wait. Could anyone give us some suggestion? Any comments would be highly appreciated. > > goto restore_opts; > > - if (!ext3_setup_super (sb, es, 0)) > > - sb->s_flags &= ~MS_RDONLY; > > + if (ext3_setup_super (sb, es, 0)) > > + *flags &= ~MS_RDONLY; > > } > > } > > #ifdef CONFIG_QUOTA > > ---------- > > -- Thanks. Signed-off-by :Tadao Uchiyama <Tadao.Uchiyama@xxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
