Skip to contentSkip to conversation

ide barrier support, #2

PATCH Andi Kleen 3 participants 6 messages Oct 14, 2003 1 message not in the archive XFS filesystem

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Andi Kleen

author
#1 lore raw

Jens Axboe <[email protected]> writes:

This adds support for XFS for log writes (not for fsync). Based on the 2.4 XFS patch for write barriers I did some time ago.

It just does a flush, not a barrier. I think that's enough for log writes because XFS waits until the log write has hit disk.

It doesn't do anything special when the flush fails - just shuts down the file system as usual.

fs/xfs/pagebuf/page_buf.c renamed from fs/xfs/pagebuf/page_buf.c-o +6 -6
diff -u linux/fs/xfs/pagebuf/page_buf.c-o linux-2.6.0test6-work/fs/xfs/pagebuf/page_buf.c
@@ -1403,12 +1403,12 @@
 
 submit_io:
 	if (likely(bio->bi_size)) {
-		if (pb->pb_flags & PBF_READ) {
-			submit_bio(READ, bio);
-		} else {
-			submit_bio(WRITE, bio);
-		}
-
+		int cmd = WRITE; 
+		if (pb->pb_flags & PBF_READ)
+			cmd = READ;
+		else if (pb->pb_flags & PBF_FLUSH)
+			cmd = WRITESYNC;
+		submit_bio(cmd, bio);
 		if (size)
 			goto next_chunk;
 	} else {
#2 lore raw
Quoted 19 lines · Andi Kleen

Jens Axboe <[email protected]> writes:

This adds support for XFS for log writes (not for fsync). Based on the 2.4 XFS patch for write barriers I did some time ago.

It just does a flush, not a barrier. I think that's enough for log writes because XFS waits until the log write has hit disk.

It doesn't do anything special when the flush fails - just shuts down the file system as usual.

diff -u linux/fs/xfs/pagebuf/page_buf.c-o linux-2.6.0test6-work/fs/xfs/pagebuf/page_buf.c

fs/xfs/pagebuf/page_buf.c renamed from fs/xfs/pagebuf/page_buf.c-o +0 -1
@@ -1403,12 +1403,12 @@
 
 submit_io:
 	if (likely(bio->bi_size)) {
-		if (pb->pb_flags & PBF_READ) {

fs/xfs/pagebuf/page_buf.c line 1410

Quoted 10 lines
fs/xfs/pagebuf/page_buf.c renamed from fs/xfs/pagebuf/page_buf.c-o +5 -5
-			submit_bio(READ, bio);
-		} else {
-			submit_bio(WRITE, bio);
-		}
-
+		int cmd = WRITE; 
+		if (pb->pb_flags & PBF_READ)
+			cmd = READ;
+		else if (pb->pb_flags & PBF_FLUSH)
+			cmd = WRITESYNC;

Uh be careful! It must be WRITEBARRIER, not WRITESYNC. I think I'll kill WRITEBARRIER and just call it WRITESYNC, it's more logical. I've added the modified variant, thanks.

Signature · 1 line
Jens Axboe
#3 lore raw
Quoted 3 lines

Uh be careful! It must be WRITEBARRIER, not WRITESYNC. I think I'll kill WRITEBARRIER and just call it WRITESYNC, it's more logical. I've added the modified variant, thanks.

Why? The journaling just checks if the write finished and then submits the dependent writes. It doesn't care about reordering.

As long as WRITESYNC guarantees that the data hit disk when completed then it should be ok.

-Andi

#4 lore raw
Quoted 6 lines · Andi Kleen
Quoted 3 lines

Uh be careful! It must be WRITEBARRIER, not WRITESYNC. I think I'll kill WRITEBARRIER and just call it WRITESYNC, it's more logical. I've added the modified variant, thanks.

Why? The journaling just checks if the write finished and then submits the dependent writes. It doesn't care about reordering.

See the patch, WRITESYNC is used solely internally in raid1. WRITEBARRIER is a bitmask of BIO_RW and BIO_RW_BARRIER and that is what you want. I'll make that more clear. Writes will not be reordered around the barrier either, btw.

Quoted 2 lines

As long as WRITESYNC guarantees that the data hit disk when completed then it should be ok.

Yep.

Signature · 1 line
Jens Axboe
#5 lore raw
Quoted 4 lines

See the patch, WRITESYNC is used solely internally in raid1. WRITEBARRIER is a bitmask of BIO_RW and BIO_RW_BARRIER and that is what you want. I'll make that more clear. Writes will not be reordered around the barrier either, btw.

It would be still misnamed. I want a flush and not a barrier.

Anyways, when you apply the patch just change the cmd that what you think is right.

-Andi

#6 lore raw
Quoted 6 lines · Andi Kleen
Quoted 4 lines

See the patch, WRITESYNC is used solely internally in raid1. WRITEBARRIER is a bitmask of BIO_RW and BIO_RW_BARRIER and that is what you want. I'll make that more clear. Writes will not be reordered around the barrier either, btw.

It would be still misnamed. I want a flush and not a barrier.

Don't you still require previously submitted writes to have hit platter before your flush goes down?

Quoted 2 lines

Anyways, when you apply the patch just change the cmd that what you think is right.

I did :)

Signature · 1 line
Jens Axboe