blktrace: treat flush as barrier
Subsystems (2)
PATCH 1/2 blktrace: treat flush as barrier
Since BARRIER requests have been converted to FLUSH/FUA, it would be better for blktrace to recognize FLUSH requests as BARRIER for the backward-compatibility IMHO.
--- kernel/trace/blktrace.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
kernel/trace/blktrace.c +2 -0
@@ -176,6 +176,7 @@ static const u32 ddir_act[2] = { BLK_TC_ACT(BLK_TC_READ), BLK_TC_ACT(BLK_TC_WRITE) };#define BLK_TC_RAHEAD BLK_TC_AHEAD +#define BLK_TC_FLUSH BLK_TC_BARRIER/* The ilog2() calls fall out because they're constant */ #define MASK_TC_BIT (rw, __name) ((rw & REQ_ ## __name) << \
@@ -206,6 +207,7 @@ static void __blk_add_trace(struct blk_trace *bt, sector_t sector, int bytes, what |=MASK_TC_BIT (rw,RAHEAD ); what |=MASK_TC_BIT (rw,META ); what |=MASK_TC_BIT (rw,DISCARD ); + what |=MASK_TC_BIT (rw,FLUSH ); pid = tsk->pid;if (act_log_check (bt, what, sector, pid))
Signature · 1 line
1.7.5.2
PATCH 2/2 block: add REQ_SECURE to REQ_COMMON_MASK
Add REQ_SECURE flag to REQ_COMMON_MASK so that init_request_from_bio() can pass it to @req->cmd_flags.
---
I couldn't find where the flag is passed from bio to req and don't know how mmc - it seems that it's the only user of the flag, AFAICS - works by now. Maybe I'm missing something. :)
include/linux/blk_types.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
include/linux/blk_types.h +1 -1
@@ -168,7 +168,7 @@ enum rq_flag_bits { (REQ_FAILFAST_DEV | REQ_FAILFAST_TRANSPORT | REQ_FAILFAST_DRIVER)#define REQ_COMMON_MASK \ (REQ_WRITE | REQ_FAILFAST_MASK | REQ_SYNC | REQ_META | REQ_DISCARD | \ - REQ_NOIDLE | REQ_FLUSH | REQ_FUA) + REQ_NOIDLE | REQ_FLUSH | REQ_FUA | REQ_SECURE)#define REQ_CLONE_MASK REQ_COMMON_MASK#define REQ_RAHEAD (1 << __REQ_RAHEAD)
Signature · 1 line
1.7.5.2
Quoted 3 lines · Namhyung Kim
Since BARRIER requests have been converted to FLUSH/FUA, it would be better for blktrace to recognize FLUSH requests as BARRIER for the backward-compatibility IMHO.
I'd rather see new flags for them. F and U maybe?
Quoted 6 lines · Christoph Hellwig
Quoted 3 lines · Namhyung Kim
Since BARRIER requests have been converted to FLUSH/FUA, it would be better for blktrace to recognize FLUSH requests as BARRIER for the backward-compatibility IMHO.
I'd rather see new flags for them. F and U maybe?
Somehow I'm not surprised by your F and U suggestion -- appropriate on multiple levels :)
2011-05-27 (금), 09:57 -0400, Mike Snitzer:
Quoted 10 lines · Christoph Hellwig
Quoted 6 lines · Namhyung Kim
Quoted 3 lines
Since BARRIER requests have been converted to FLUSH/FUA, it would be better for blktrace to recognize FLUSH requests as BARRIER for the backward-compatibility IMHO.
I'd rather see new flags for them. F and U maybe?
Somehow I'm not surprised by your F and U suggestion -- appropriate on multiple levels :)
OK. I'll work on that direction.
Thanks.
Signature · 2 lines
Regards, Namhyung Kim
Quoted 7 lines · Namhyung Kim
2011-05-27 (금), 09:57 -0400, Mike Snitzer:
Quoted 6 lines · Christoph Hellwig
Quoted 5 lines · Namhyung Kim
Quoted 3 lines
Since BARRIER requests have been converted to FLUSH/FUA, it would be better for blktrace to recognize FLUSH requests as BARRIER for the backward-compatibility IMHO.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
I'd rather see new flags for them. F and U maybe?
Somehow I'm not surprised by your F and U suggestion -- appropriate on multiple levels :)
OK. I'll work on that direction.
Thanks.
Agree on Christophs comments, we should not pretend they are the same (since they are not). Since flush is a request on its own, F works nicely. For FUA it's associated with a write, so F should work there too indicating Write Fua (and easily humanly parsed as that, or Write Flush). WU would look confusing.
Signature · 1 line
Jens Axboe
Quoted 5 lines · Jens Axboe
Agree on Christophs comments, we should not pretend they are the same (since they are not). Since flush is a request on its own, F works nicely. For FUA it's associated with a write, so F should work there too indicating Write Fua (and easily humanly parsed as that, or Write Flush). WU would look confusing.
REQ_FLUSH can also be set on a write bio, it only gets split at the request level. And even there we're at least pondering allowing it to stay as part of the write for some paravirtualized storage protocols.
2011-05-27 (금), 16:27 -0400, Christoph Hellwig:
Quoted 11 lines · Jens Axboe
Quoted 5 lines
Agree on Christophs comments, we should not pretend they are the same (since they are not). Since flush is a request on its own, F works nicely. For FUA it's associated with a write, so F should work there too indicating Write Fua (and easily humanly parsed as that, or Write Flush). WU would look confusing.
REQ_FLUSHcan also be set on a write bio, it only gets split at the request level. And even there we're at least pondering allowing it to stay as part of the write for some paravirtualized storage protocols.
Hi,
AFAIK FLUSH always precedes WRITE and then followed by FUA, so how about using the same F for both of them and distinguishing by position?
- WRITE: W - WRITE_FLUSH: FW - WRITE_FUA: WF - WRITE_FLUSH_FUA: FWF
Or using lower-case 'f' for FUA?
Thanks.
Signature · 2 lines
Regards, Namhyung Kim
Quoted 1 line · Namhyung Kim
AFAIK FLUSH always precedes WRITE and then followed by FUA, so how about
Right now most do because that's how the old barriers worked, but it's going to change. For $NEXT + 1 I have a patch that for will make xfs sends FUA without flushes in a lot of cases, and afaik some device mapper code already does now.
2011-05-28 (토), 03:44 -0400, Christoph Hellwig:
Quoted 8 lines · Namhyung Kim
Quoted 1 line
AFAIK FLUSH always precedes WRITE and then followed by FUA, so how about
Right now most do because that's how the old barriers worked, but it's going to change. For $NEXT + 1 I have a patch that for will make xfs sends FUA without flushes in a lot of cases, and afaik some device mapper code already does now.
OK, thanks for the explanation.
Btw, the point was it seems possible that we can use the 'F' for both FLUSH and FUA if we distinguish them by their (relative) position in the output. How do you think? Do you still prefer F/U flags?
Thanks.
Signature · 2 lines
Regards, Namhyung Kim
Quoted 15 lines · Namhyung Kim
2011-05-27 (금), 16:27 -0400, Christoph Hellwig:
Quoted 11 lines · Jens Axboe
Quoted 5 lines
Agree on Christophs comments, we should not pretend they are the same (since they are not). Since flush is a request on its own, F works nicely. For FUA it's associated with a write, so F should work there too indicating Write Fua (and easily humanly parsed as that, or Write Flush). WU would look confusing.
REQ_FLUSHcan also be set on a write bio, it only gets split at the request level. And even there we're at least pondering allowing it to stay as part of the write for some paravirtualized storage protocols.Hi,
Quoted 7 lines
AFAIK FLUSH always precedes WRITE and then followed by FUA, so how about using the same F for both of them and distinguishing by position?
- WRITE: W - WRITE_FLUSH: FW - WRITE_FUA: WF - WRITE_FLUSH_FUA: FWF
That looks fine. 'U' would be an illogical choice.
Signature · 1 line
Jens Axboe