Skip to contentSkip to conversation

enable write barriers by default

PATCH In review Chris Mason 2 participants 5 messages Aug 4, 2006 – Aug 5, 2006 VFS

lore
Share & tools
lore
#0 lore raw

cover enable write barriers by default

Hello everyone,

ReiserFS and ext3 have had code to support forcing cache flushes for a while, but it has been off by default.

These two patches enable it by default on both filesystems. Disabling barriers can be done with:

mount -o barrier=none in reiser
mount -o barrier=0 in ext3

-chris

#1 lore raw

PATCH 1/2 Make reiserfs default to barrier=flush

From: Chris Mason <[email protected]>
Subject: Make reiserfs default to barrier=flush

Change the default reiserfs mount option to barrier=flush

fs/reiserfs/super.c +5 -2
@@ -1785,9 +1785,12 @@ static int reiserfs_fill_super(struct su
 	} else {
 		reiserfs_info(s, "using writeback data mode\n");
 	}
-	if (reiserfs_barrier_flush(s)) {
+	/* make barrer=flush the default */
+
+	if (!reiserfs_barrier_none(s))
+		REISERFS_SB(s)->s_mount_opt |= (1 << REISERFS_BARRIER_FLUSH);
+	if (reiserfs_barrier_flush(s))
 		printk("reiserfs: using flush barriers\n");
-	}
 	// set_device_ro(s->s_dev, 1) ;
 	if (journal_init(s, jdev_name, old_format, commit_max_age)) {
 		SWARN(silent, s,
#2 lore raw

PATCH 2/2 make ext3 mount default to barrier=1

In reply to Chris Mason

From: Chris Mason <[email protected]>
Subject: make ext3 mount default to barrier=1

This patch turns on barriers by default for ext3. mount -o barrier=0 will turn them off. It also changes the ext3 fsync call to trigger a barrier when a commit isn't done.

fs/ext3/fsync.c +4 -0
@@ -27,6 +27,7 @@
 #include <linux/sched.h>
 #include <linux/writeback.h>
 #include <linux/jbd.h>
+#include <linux/blkdev.h>
 #include <linux/ext3_fs.h>
 #include <linux/ext3_jbd.h>
 
@@ -81,7 +82,10 @@ int ext3_sync_file(struct file * file, s
 			.sync_mode = WB_SYNC_ALL,
 			.nr_to_write = 0, /* sys_fsync did this */
 		};
+		journal_t *journal = EXT3_SB(inode->i_sb)->s_journal;
 		ret = sync_inode(inode, &wbc);
+		if (journal && (journal->j_flags & JFS_BARRIER))
+			blkdev_issue_flush(inode->i_sb->s_bdev, NULL);
 	}
 out:
 	return ret;
fs/ext3/super.c +2 -0
diff -r b1d8075ee99b fs/ext3/super.c
@@ -1423,6 +1423,8 @@ static int ext3_fill_super (struct super
 	sbi->s_resuid = le16_to_cpu(es->s_def_resuid);
 	sbi->s_resgid = le16_to_cpu(es->s_def_resgid);
 
+	/* enable barriers by default */
+	set_opt(sbi->s_mount_opt, BARRIER);
 	set_opt(sbi->s_mount_opt, RESERVATION);
 
 	if (!parse_options ((char *) data, sb, &journal_inum, &journal_devnum,
#3 lore raw
In reply to Chris Mason
Quoted 5 lines · Chris Mason

Hello everyone,

ReiserFS and ext3 have had code to support forcing cache flushes for a while, but it has been off by default.

Quoted 12 lines

These two patches enable it by default on both filesystems. Disabling barriers can be done with:

mount -o barrier=none in reiser
mount -o barrier=0 in ext3

-chris

Please explain when cache flushes occur now. For every fsync on a drive that does not support write barriers? Which drives support it?

Did this only get enabled now because it is only now that someone from the press is paying attention to it?

This is the price we paid for losing Andre, yes?

#4 lore raw
Quoted 2 lines · Hans Reiser

Please explain when cache flushes occur now.

Without them enabled? Never. With them enabled on every commit and/or fsync.

Quoted 2 lines

For every fsync on a drive
that does not support write barriers? Which drives support it?

Most IDE and SATA drives.

Quoted 3 lines

Did this only get enabled now because it is only now that someone from the press is paying attention to it?

No, it has been enabled by default in the SUSE kernels for a long time (two enterprise releases now sles9 and sles10). I wanted to bring the discussion about it into mainline.

Quoted 2 lines

This is the price we paid for losing Andre, yes?

This is the price we pay for drives turning writeback cache on by default. It happens for performance, because without tagging write though caches give horrible write speeds. It is slower than not doing IO (writeback cache) but faster than turning writeback caches off.

Exact benchmarks vary by drive, but it is never slower than write-through caching, and almost always faster.

-chris