I revert this commit:
diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
index e5ff12e..2f36743 100644
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -489,6 +489,12 @@ static void bch_insert_data_loop(struct closure *cl)
bch_queue_gc(op->c);
}
+ /*
+ * Journal writes are marked REQ_FLUSH; if the original write was a
+ * flush, it'll wait on the journal write.
+ */
+ bio->bi_rw &= ~(REQ_FLUSH|REQ_FUA);
+
do {
unsigned i;
struct bkey *k;
@@ -716,7 +722,7 @@ static struct search *search_alloc(struct bio *bio,
struct bcache_device *d)
s->task = current;
s->orig_bio = bio;
s->write = (bio->bi_rw & REQ_WRITE) != 0;
- s->op.flush_journal = (bio->bi_rw & REQ_FLUSH) != 0;
+ s->op.flush_journal = (bio->bi_rw & (REQ_FLUSH|REQ_FUA)) != 0;
s->op.skip = (bio->bi_rw & REQ_DISCARD) != 0;
s->recoverable = 1;
s->start_time = jiffies;
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 6817ea4..0932580 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -766,6 +766,8 @@ static int bcache_device_init(struct bcache_device
*d, unsigned block_size)
set_bit(QUEUE_FLAG_NONROT, &d->disk->queue->queue_flags);
set_bit(QUEUE_FLAG_DISCARD, &d->disk->queue->queue_flags);
+ blk_queue_flush(q, REQ_FLUSH|REQ_FUA);
+
return 0;
}
the strange behaviour is gone. And I checked the bcache-testing, it does
not contain that commit any more, maybe I'm lost in the git tree update.
Anyway, thanks Kent for your kindly support.
Jack
On 2013年04月22日 21:15, Jack Wang wrote:
> Hi all,
>
> We've seen strange behaviour in bcache mode in current bcache-testing
> branch with Possible allocator fix:
>
> Once I start writing data with "dd if=/dev/zero of=/dev/bcache0 bs=4k
> count=10000 oflag=sync", all SSDs in the Pool go close to 100% util and
> I see about 3600 writes/second in iostat for each disk in the pool, BUT
> no data written in means of throughput.
>
> Then after some seconds (the flush interval of bcache) I see the flush
> of the writeback and also data written to the pool SSDs which looks
> pretty much like reordering and merging happened for that data.
>
> bcache-3.2 does not have such problem.
> only bcache(master) and bcache-testing have such problem.
>
> What's the possible reason?
>
> Regards,
> Jack
>
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
