From: Pavel Machek <pavel@ucw.cz>
To: kernel list <linux-kernel@vger.kernel.org>
Subject: ext3: bump mount count on journal replay
Date: Wed, 14 Jul 2004 15:15:25 +0200 [thread overview]
Message-ID: <20040714131525.GA1369@elf.ucw.cz> (raw)
Hi!
Currently, you get fsck "just to be sure" once every ~30 clean
mounts or ~30 hard shutdowns. I believe that hard shutdown is way more
likely to cause some disk corruption, so it would make sense to fsck
more often when system is hit by hard shutdown.
What about this patch?
Pavel
--- clean.amd/fs/ext3/super.c 2004-06-22 12:38:25.000000000 +0200
+++ linux/fs/ext3/super.c 2004-07-07 22:50:26.000000000 +0200
@@ -919,7 +919,7 @@
}
static int ext3_setup_super(struct super_block *sb, struct ext3_super_block *es,
- int read_only)
+ int read_only, int mount_cost)
{
struct ext3_sb_info *sbi = EXT3_SB(sb);
int res = 0;
@@ -960,7 +961,7 @@
if (!(__s16) le16_to_cpu(es->s_max_mnt_count))
es->s_max_mnt_count =
(__s16) cpu_to_le16(EXT3_DFL_MAX_MNT_COUNT);
- es->s_mnt_count=cpu_to_le16(le16_to_cpu(es->s_mnt_count) + 1);
+ es->s_mnt_count=cpu_to_le16(le16_to_cpu(es->s_mnt_count) + mount_cost);
es->s_mtime = cpu_to_le32(get_seconds());
ext3_update_dynamic_rev(sb);
EXT3_SET_INCOMPAT_FEATURE(sb, EXT3_FEATURE_INCOMPAT_RECOVER);
@@ -1214,7 +1215,7 @@
int hblock;
int db_count;
int i;
- int needs_recovery;
+ int needs_recovery, mount_cost = 1;
sbi = kmalloc(sizeof(*sbi), GFP_KERNEL);
if (!sbi)
@@ -1484,9 +1485,11 @@
* root first: it may be modified in the journal!
*/
if (!test_opt(sb, NOLOAD) &&
- EXT3_HAS_COMPAT_FEATURE(sb, EXT3_FEATURE_COMPAT_HAS_JOURNAL)) {
- if (ext3_load_journal(sb, es))
- goto failed_mount2;
+ EXT3_HAS_COMPAT_FEATURE(sb, EXT3_FEATURE_COMPAT_HAS_JOURNAL)) { {
+ mount_cost = 5;
+ if (ext3_load_journal(sb, es))
+ goto failed_mount2;
+ }
} else if (journal_inum) {
if (ext3_create_journal(sb, es, journal_inum))
goto failed_mount2;
@@ -1543,7 +1546,7 @@
goto failed_mount3;
}
- ext3_setup_super (sb, es, sb->s_flags & MS_RDONLY);
+ ext3_setup_super (sb, es, sb->s_flags & MS_RDONLY, mount_cost);
/*
* akpm: core read_super() calls in here with the superblock locked.
* That deadlocks, because orphan cleanup needs to lock the superblock
@@ -2069,7 +2072,7 @@
*/
ext3_clear_journal_err(sb, es);
sbi->s_mount_state = le16_to_cpu(es->s_state);
- if (!ext3_setup_super (sb, es, 0))
+ if (!ext3_setup_super (sb, es, 0, 1))
sb->s_flags &= ~MS_RDONLY;
}
}
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
next reply other threads:[~2004-07-14 13:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-14 13:15 Pavel Machek [this message]
2004-07-14 19:55 ` ext3: bump mount count on journal replay Theodore Ts'o
2004-07-14 20:30 ` Pavel Machek
2004-07-14 20:05 ` Andreas Dilger
2004-07-14 20:32 ` Pavel Machek
2004-07-16 20:41 ` [Ext2-devel] " Andreas Dilger
2004-07-16 21:06 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040714131525.GA1369@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.