From: Andrew Morton <akpm@digeo.com>
To: Chris Mason <mason@suse.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"Stephen C. Tweedie" <sct@redhat.com>
Subject: Re: [PATCH] 2.5.x write_super is not for syncing
Date: Mon, 02 Dec 2002 19:09:52 -0800 [thread overview]
Message-ID: <3DEC2080.D801BA13@digeo.com> (raw)
In-Reply-To: 3DEC0BA4.70E2E344@digeo.com
Andrew Morton wrote:
>
> These two patches are what I'll be testing tonight for 2.5.
>
I don't feel inclined to take on the whole sync thing at present.
So a minimal fix for this problem is as follows. Against 2.4.20:
fs/buffer.c | 2 ++
fs/super.c | 4 ++++
include/linux/fs.h | 1 +
3 files changed, 7 insertions(+)
--- linux-akpm/fs/buffer.c~commit-fs Mon Dec 2 18:40:03 2002
+++ linux-akpm-akpm/fs/buffer.c Mon Dec 2 18:41:34 2002
@@ -327,6 +327,8 @@ int fsync_super(struct super_block *sb)
lock_super(sb);
if (sb->s_dirt && sb->s_op && sb->s_op->write_super)
sb->s_op->write_super(sb);
+ if (sb->s_op && sb->s_op->sync_fs)
+ sb->s_op->sync_fs(sb);
unlock_super(sb);
unlock_kernel();
--- linux-akpm/include/linux/fs.h~commit-fs Mon Dec 2 18:40:23 2002
+++ linux-akpm-akpm/include/linux/fs.h Mon Dec 2 18:40:56 2002
@@ -894,6 +894,7 @@ struct super_operations {
void (*delete_inode) (struct inode *);
void (*put_super) (struct super_block *);
void (*write_super) (struct super_block *);
+ int (*sync_fs) (struct super_block *);
void (*write_super_lockfs) (struct super_block *);
void (*unlockfs) (struct super_block *);
int (*statfs) (struct super_block *, struct statfs *);
--- linux-akpm/fs/super.c~commit-fs Mon Dec 2 18:44:01 2002
+++ linux-akpm-akpm/fs/super.c Mon Dec 2 18:44:07 2002
@@ -454,6 +454,8 @@ void sync_supers(kdev_t dev)
if (sb) {
if (sb->s_dirt)
write_super(sb);
+ if (sb->s_op && sb->s_op->sync_fs)
+ sb->s_op->sync_fs(sb);
drop_super(sb);
}
return;
@@ -467,6 +469,8 @@ restart:
spin_unlock(&sb_lock);
down_read(&sb->s_umount);
write_super(sb);
+ if (sb->s_op && sb->s_op->sync_fs)
+ sb->s_op->sync_fs(sb);
drop_super(sb);
goto restart;
} else
_
and
fs/ext3/super.c | 25 +++++++++++++------------
1 files changed, 13 insertions(+), 12 deletions(-)
--- linux-akpm/fs/ext3/super.c~ext3_sync_fs Mon Dec 2 18:45:10 2002
+++ linux-akpm-akpm/fs/ext3/super.c Mon Dec 2 18:46:59 2002
@@ -47,6 +47,8 @@ static void ext3_mark_recovery_complete(
static void ext3_clear_journal_err(struct super_block * sb,
struct ext3_super_block * es);
+static int ext3_sync_fs(struct super_block * sb);
+
#ifdef CONFIG_JBD_DEBUG
int journal_no_write[2];
@@ -454,6 +456,7 @@ static struct super_operations ext3_sops
delete_inode: ext3_delete_inode, /* BKL not held. We take it */
put_super: ext3_put_super, /* BKL held */
write_super: ext3_write_super, /* BKL held */
+ sync_fs: ext3_sync_fs,
write_super_lockfs: ext3_write_super_lockfs, /* BKL not held. Take it */
unlockfs: ext3_unlockfs, /* BKL not held. We take it */
statfs: ext3_statfs, /* BKL held */
@@ -1577,24 +1580,22 @@ int ext3_force_commit(struct super_block
* This implicitly triggers the writebehind on sync().
*/
-static int do_sync_supers = 0;
-MODULE_PARM(do_sync_supers, "i");
-MODULE_PARM_DESC(do_sync_supers, "Write superblocks synchronously");
-
void ext3_write_super (struct super_block * sb)
{
+ if (down_trylock(&sb->s_lock) == 0)
+ BUG();
+ sb->s_dirt = 0;
+ log_start_commit(EXT3_SB(sb)->s_journal, NULL);
+}
+
+static int ext3_sync_fs(struct super_block *sb)
+{
tid_t target;
- if (down_trylock(&sb->s_lock) == 0)
- BUG(); /* aviro detector */
sb->s_dirt = 0;
target = log_start_commit(EXT3_SB(sb)->s_journal, NULL);
-
- if (do_sync_supers) {
- unlock_super(sb);
- log_wait_commit(EXT3_SB(sb)->s_journal, target);
- lock_super(sb);
- }
+ log_wait_commit(EXT3_SB(sb)->s_journal, target);
+ return 0;
}
/*
_
next prev parent reply other threads:[~2002-12-03 3:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1034791206.18503.68.camel@tiny>
2002-12-02 22:07 ` [PATCH] 2.5.x write_super is not for syncing Andrew Morton
2002-12-02 23:40 ` Chris Mason
2002-12-03 0:03 ` Andrew Morton
2002-12-03 1:10 ` Chris Mason
2002-12-03 1:40 ` Andrew Morton
2002-12-03 3:09 ` Andrew Morton [this message]
2002-12-03 19:36 ` Bryan Henderson
2002-12-03 20:06 ` Andrew Morton
2002-12-03 21:41 ` Bryan Henderson
2002-12-03 22:13 ` Andrew Morton
2002-12-04 2:05 ` Bryan Henderson
2002-12-04 4:29 ` Andrew Morton
2002-12-04 19:00 ` Bryan Henderson
2002-12-04 19:23 ` Matthew Wilcox
2002-12-04 22:17 ` Bryan Henderson
2002-12-05 10:36 ` Arnaldo Carvalho de Melo
2002-12-05 16:31 ` Stephen C. Tweedie
2002-12-05 17:24 ` girish
2002-12-04 21:10 ` Stephen C. Tweedie
2002-12-04 22:46 ` Bryan Henderson
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=3DEC2080.D801BA13@digeo.com \
--to=akpm@digeo.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mason@suse.com \
--cc=sct@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox