On 2017/7/20 上午12:05, Bob Peterson wrote: > ----- Original Message ----- > | >> This patch adds REQ_PRIO flag when submitting a metadata readahead bio. > | >> A meta data read ahead bio may come from I/O requests for bitmap, > | >> directoriesmeta or other general metadata request. > | >> > | > > | > Are there any places in gfs2 where REQ_PRIO should be placed on > | > latency-sensitive metadata writes? They would then writeback in bcache > | > after the relevant bcache patch is merged. > | > | Hi Eric, > | > | I just grep REQ_META in fs/gfs2, there are 10 locations use REQ_META. > | Among the 10 locations, REQ_PRIO shows up at 3 locations, another 3 > | locations are REQ_READAHEAD and I add REQ_PRIO to them, the rested > | locations are, > | > | 1) log.c:662 > | In log_write_header(), used to flush gfs2 log header. The author does > | not add REQ_PRIO on purpose, because I see REQ_FUA is there. And for no > | barrier condition, REQ_PRIO is added with REQ_FUA removed. So it's well > | done here. > | > | 2) meta_io.c:455 > | Here gfs2_meta_ra() tries to read first metadata block, cache the > | metadata block in bcache should be helpful. > | > | 3) ops_fstype.c:250 > | This is for gfs2_read_sb(), it is only called once by init_sb(), we > | don't need to cache this block by bcache. > | > | 4) quota.c:733 > | This is in gfs2_write_buf_to_page() when gfs2 disk quota is updated, > | we can have it in cache device. > | > | So it seems REQ_PRIO might be added at meta_io.c:455, and quota.c:733 to > | provide more hint to bcache. > | > | Thanks for suggestion. > | > | Coly > > Hi Coly, > > So does this mean you are revising the patch and I should wait for a new one? > Or is this patch good as it is? BTW, you may want to change > the comment from "directoriesmeta" to "directory meta". > > Regards, > Hi Bob, It's great o hear from you :-) Yes I will post a V2 (not RFC) patch for review, with comment typo fix. Thanks for your replying ! -- Coly Li -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
