On Fri, Mar 7, 2014 at 3:44 PM, Brian Norris <[email protected]> wrote: > On Thu, Jan 02, 2014 at 01:21:21AM +0900, Roman Pen wrote: >> From: Roman Peniaev <[email protected]> >> >> mtd_blkdevs is device with volatile cache (writeback buffer), so it should >> support >> REQ_FLUSH to do explicit flush. >> >> Without this patch 'sync' does not guarantee that writeback buffer will be >> flushed >> on disk in case of power off, e.g.: >> >> $ cp some_file /mnt >> $ sync >> >> ### POWER OFF >> >> In case of this sequence writeback buffer will not be flushed on disk. >> >> This patch fixes this behaviour and explicitly reports to block layer that >> flush >> requests are being supported. >> >> Signed-off-by: Roman Peniaev <[email protected]> >> CC: David Woodhouse <[email protected]> >> CC: [email protected] >> CC: [email protected] >> --- >> drivers/mtd/mtd_blkdevs.c | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c >> index 5073cbc..feafe5c 100644 >> --- a/drivers/mtd/mtd_blkdevs.c >> +++ b/drivers/mtd/mtd_blkdevs.c >> @@ -89,6 +89,12 @@ static int do_blktrans_request(struct mtd_blktrans_ops >> *tr, >> if (req->cmd_type != REQ_TYPE_FS) >> return -EIO; >> >> + if (req->cmd_flags & REQ_FLUSH) { >> + if (tr->flush) >> + return tr->flush(dev); >> + return 0; >> + } >> + >> if (blk_rq_pos(req) + blk_rq_cur_sectors(req) > >> get_capacity(req->rq_disk)) >> return -EIO; >> @@ -409,6 +415,8 @@ int add_mtd_blktrans_dev(struct mtd_blktrans_dev *new) >> if (!new->rq) >> goto error3; >> >> + blk_queue_flush(new->rq, REQ_FLUSH); > > How about only registering the flush command if we support it? So: > > if (tr->flush) > blk_queue_flush(new->rq, REQ_FLUSH);
Yep, that's better. Will send v2. -- Roman > > Then you can probably also change the earlier hunk to the following, no? > > if (req->cmd_flags & REQ_FLUSH) > return tr->flush(dev); > >> + >> new->rq->queuedata = new; >> blk_queue_logical_block_size(new->rq, tr->blksize); >> > > Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
