* [PATCH V2 0/3] block/loop: handle discard/zeroout error
@ 2017-09-07 0:13 Shaohua Li
2017-09-07 0:13 ` [PATCH V2 1/3] block/loop: don't hijack error number Shaohua Li
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Shaohua Li @ 2017-09-07 0:13 UTC (permalink / raw)
To: linux-block; +Cc: kernel-team, axboe, Shaohua Li
From: Shaohua Li <shli@fb.com>
Fix some problems when setting up loop device with a block device as back file
and create/mount ext4 in the loop device.
BTW: blkdev_issue_zeroout retries if we immediately find the device doesn't
support zeroout, but it doesn't retry if submit_bio_wait returns -EOPNOTSUPP.
Is this correct behavior?
Thanks,
Shaohua
Shaohua Li (3):
block/loop: don't hijack error number
block/loop: use FALLOC_FL_ZERO_RANGE for REQ_OP_WRITE_ZEROES
block/loop: suppress discard IO error message
drivers/block/loop.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
--
2.9.5
^ permalink raw reply [flat|nested] 10+ messages in thread* [PATCH V2 1/3] block/loop: don't hijack error number
2017-09-07 0:13 [PATCH V2 0/3] block/loop: handle discard/zeroout error Shaohua Li
@ 2017-09-07 0:13 ` Shaohua Li
2017-09-07 9:22 ` Ming Lei
2017-09-07 0:13 ` [PATCH V2 2/3] block/loop: use FALLOC_FL_ZERO_RANGE for REQ_OP_WRITE_ZEROES Shaohua Li
2017-09-07 0:13 ` [PATCH V2 3/3] block/loop: suppress discard IO error message Shaohua Li
2 siblings, 1 reply; 10+ messages in thread
From: Shaohua Li @ 2017-09-07 0:13 UTC (permalink / raw)
To: linux-block; +Cc: kernel-team, axboe, Shaohua Li
From: Shaohua Li <shli@fb.com>
If the bio returns -EOPNOTSUPP, we shouldn't hijack it and return -EIO
Signed-off-by: Shaohua Li <shli@fb.com>
---
drivers/block/loop.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 85de673..715b762 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -460,7 +460,7 @@ static void lo_complete_rq(struct request *rq)
zero_fill_bio(bio);
}
- blk_mq_end_request(rq, cmd->ret < 0 ? BLK_STS_IOERR : BLK_STS_OK);
+ blk_mq_end_request(rq, errno_to_blk_status(cmd->ret));
}
static void lo_rw_aio_do_completion(struct loop_cmd *cmd)
@@ -476,7 +476,7 @@ static void lo_rw_aio_complete(struct kiocb *iocb, long ret, long ret2)
{
struct loop_cmd *cmd = container_of(iocb, struct loop_cmd, iocb);
- cmd->ret = ret;
+ cmd->ret = ret > 0 ? 0 : ret;
lo_rw_aio_do_completion(cmd);
}
@@ -1706,7 +1706,7 @@ static void loop_handle_cmd(struct loop_cmd *cmd)
failed:
/* complete non-aio request */
if (!cmd->use_aio || ret) {
- cmd->ret = ret ? -EIO : 0;
+ cmd->ret = ret;
blk_mq_complete_request(cmd->rq);
}
}
--
2.9.5
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH V2 1/3] block/loop: don't hijack error number
2017-09-07 0:13 ` [PATCH V2 1/3] block/loop: don't hijack error number Shaohua Li
@ 2017-09-07 9:22 ` Ming Lei
0 siblings, 0 replies; 10+ messages in thread
From: Ming Lei @ 2017-09-07 9:22 UTC (permalink / raw)
To: Shaohua Li; +Cc: linux-block, FB Kernel Team, Jens Axboe, Shaohua Li
On Thu, Sep 7, 2017 at 8:13 AM, Shaohua Li <shli@kernel.org> wrote:
> From: Shaohua Li <shli@fb.com>
>
> If the bio returns -EOPNOTSUPP, we shouldn't hijack it and return -EIO
>
> Signed-off-by: Shaohua Li <shli@fb.com>
> ---
> drivers/block/loop.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index 85de673..715b762 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -460,7 +460,7 @@ static void lo_complete_rq(struct request *rq)
> zero_fill_bio(bio);
> }
>
> - blk_mq_end_request(rq, cmd->ret < 0 ? BLK_STS_IOERR : BLK_STS_OK);
> + blk_mq_end_request(rq, errno_to_blk_status(cmd->ret));
> }
>
> static void lo_rw_aio_do_completion(struct loop_cmd *cmd)
> @@ -476,7 +476,7 @@ static void lo_rw_aio_complete(struct kiocb *iocb, long ret, long ret2)
> {
> struct loop_cmd *cmd = container_of(iocb, struct loop_cmd, iocb);
>
> - cmd->ret = ret;
> + cmd->ret = ret > 0 ? 0 : ret;
> lo_rw_aio_do_completion(cmd);
> }
>
> @@ -1706,7 +1706,7 @@ static void loop_handle_cmd(struct loop_cmd *cmd)
> failed:
> /* complete non-aio request */
> if (!cmd->use_aio || ret) {
> - cmd->ret = ret ? -EIO : 0;
> + cmd->ret = ret;
> blk_mq_complete_request(cmd->rq);
> }
> }
> --
> 2.9.5
>
Looks fine:
Reviewed-by: Ming Lei <ming.lei@redhat.com>
--
Ming Lei
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH V2 2/3] block/loop: use FALLOC_FL_ZERO_RANGE for REQ_OP_WRITE_ZEROES
2017-09-07 0:13 [PATCH V2 0/3] block/loop: handle discard/zeroout error Shaohua Li
2017-09-07 0:13 ` [PATCH V2 1/3] block/loop: don't hijack error number Shaohua Li
@ 2017-09-07 0:13 ` Shaohua Li
2017-09-07 9:05 ` Ming Lei
2017-09-07 0:13 ` [PATCH V2 3/3] block/loop: suppress discard IO error message Shaohua Li
2 siblings, 1 reply; 10+ messages in thread
From: Shaohua Li @ 2017-09-07 0:13 UTC (permalink / raw)
To: linux-block; +Cc: kernel-team, axboe, Shaohua Li
From: Shaohua Li <shli@fb.com>
REQ_OP_WRITE_ZEROES really means zero the data. And in blkdev_fallocate,
FALLOC_FL_ZERO_RANGE will retry but FALLOC_FL_PUNCH_HOLE not, even loop
request doesn't have BLKDEV_ZERO_NOFALLBACK set.
Signed-off-by: Shaohua Li <shli@fb.com>
---
drivers/block/loop.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 715b762..8934e25 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -426,6 +426,9 @@ static int lo_discard(struct loop_device *lo, struct request *rq, loff_t pos)
int mode = FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE;
int ret;
+ if (req_op(rq) == REQ_OP_WRITE_ZEROES)
+ mode = FALLOC_FL_ZERO_RANGE | FALLOC_FL_KEEP_SIZE;
+
if ((!file->f_op->fallocate) || lo->lo_encrypt_key_size) {
ret = -EOPNOTSUPP;
goto out;
--
2.9.5
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH V2 2/3] block/loop: use FALLOC_FL_ZERO_RANGE for REQ_OP_WRITE_ZEROES
2017-09-07 0:13 ` [PATCH V2 2/3] block/loop: use FALLOC_FL_ZERO_RANGE for REQ_OP_WRITE_ZEROES Shaohua Li
@ 2017-09-07 9:05 ` Ming Lei
0 siblings, 0 replies; 10+ messages in thread
From: Ming Lei @ 2017-09-07 9:05 UTC (permalink / raw)
To: Shaohua Li; +Cc: linux-block, FB Kernel Team, Jens Axboe, Shaohua Li
On Thu, Sep 7, 2017 at 8:13 AM, Shaohua Li <shli@kernel.org> wrote:
> From: Shaohua Li <shli@fb.com>
>
> REQ_OP_WRITE_ZEROES really means zero the data. And in blkdev_fallocate,
> FALLOC_FL_ZERO_RANGE will retry but FALLOC_FL_PUNCH_HOLE not, even loop
> request doesn't have BLKDEV_ZERO_NOFALLBACK set.
>
> Signed-off-by: Shaohua Li <shli@fb.com>
> ---
> drivers/block/loop.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index 715b762..8934e25 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -426,6 +426,9 @@ static int lo_discard(struct loop_device *lo, struct request *rq, loff_t pos)
> int mode = FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE;
> int ret;
>
> + if (req_op(rq) == REQ_OP_WRITE_ZEROES)
> + mode = FALLOC_FL_ZERO_RANGE | FALLOC_FL_KEEP_SIZE;
> +
> if ((!file->f_op->fallocate) || lo->lo_encrypt_key_size) {
> ret = -EOPNOTSUPP;
> goto out;
> --
> 2.9.5
>
Looks fine,
Reviewed-by: Ming Lei <ming.lei@redhat.com>
--
Ming Lei
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH V2 3/3] block/loop: suppress discard IO error message
2017-09-07 0:13 [PATCH V2 0/3] block/loop: handle discard/zeroout error Shaohua Li
2017-09-07 0:13 ` [PATCH V2 1/3] block/loop: don't hijack error number Shaohua Li
2017-09-07 0:13 ` [PATCH V2 2/3] block/loop: use FALLOC_FL_ZERO_RANGE for REQ_OP_WRITE_ZEROES Shaohua Li
@ 2017-09-07 0:13 ` Shaohua Li
2017-09-07 9:16 ` Ming Lei
2 siblings, 1 reply; 10+ messages in thread
From: Shaohua Li @ 2017-09-07 0:13 UTC (permalink / raw)
To: linux-block; +Cc: kernel-team, axboe, Shaohua Li
From: Shaohua Li <shli@fb.com>
We don't know if fallocate really supports FALLOC_FL_PUNCH_HOLE till
fallocate is called. If it doesn't support, loop will return -EOPNOTSUPP
and we see a lot of error message printed by blk_update_request. Failure
for discard IO isn't a big problem, so we just return 0 in loop which
will suppress the IO error message.
Signed-off-by: Shaohua Li <shli@fb.com>
---
drivers/block/loop.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 8934e25..9d4545f 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -437,6 +437,9 @@ static int lo_discard(struct loop_device *lo, struct request *rq, loff_t pos)
ret = file->f_op->fallocate(file, mode, pos, blk_rq_bytes(rq));
if (unlikely(ret && ret != -EINVAL && ret != -EOPNOTSUPP))
ret = -EIO;
+
+ if (req_op(rq) == REQ_OP_DISCARD && ret == -EOPNOTSUPP)
+ ret = 0;
out:
return ret;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH V2 3/3] block/loop: suppress discard IO error message
2017-09-07 0:13 ` [PATCH V2 3/3] block/loop: suppress discard IO error message Shaohua Li
@ 2017-09-07 9:16 ` Ming Lei
2017-09-07 21:52 ` Shaohua Li
0 siblings, 1 reply; 10+ messages in thread
From: Ming Lei @ 2017-09-07 9:16 UTC (permalink / raw)
To: Shaohua Li; +Cc: linux-block, FB Kernel Team, Jens Axboe, Shaohua Li
On Thu, Sep 7, 2017 at 8:13 AM, Shaohua Li <shli@kernel.org> wrote:
> From: Shaohua Li <shli@fb.com>
>
> We don't know if fallocate really supports FALLOC_FL_PUNCH_HOLE till
> fallocate is called. If it doesn't support, loop will return -EOPNOTSUPP
> and we see a lot of error message printed by blk_update_request. Failure
> for discard IO isn't a big problem, so we just return 0 in loop which
> will suppress the IO error message.
Setting RQF_QUIET for discard IO should be more clean for suppressing error,
and upper layer can get the failure notification too.
--
Ming Lei
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH V2 3/3] block/loop: suppress discard IO error message
2017-09-07 9:16 ` Ming Lei
@ 2017-09-07 21:52 ` Shaohua Li
0 siblings, 0 replies; 10+ messages in thread
From: Shaohua Li @ 2017-09-07 21:52 UTC (permalink / raw)
To: Ming Lei; +Cc: linux-block, FB Kernel Team, Jens Axboe, Shaohua Li
On Thu, Sep 07, 2017 at 05:16:21PM +0800, Ming Lei wrote:
> On Thu, Sep 7, 2017 at 8:13 AM, Shaohua Li <shli@kernel.org> wrote:
> > From: Shaohua Li <shli@fb.com>
> >
> > We don't know if fallocate really supports FALLOC_FL_PUNCH_HOLE till
> > fallocate is called. If it doesn't support, loop will return -EOPNOTSUPP
> > and we see a lot of error message printed by blk_update_request. Failure
> > for discard IO isn't a big problem, so we just return 0 in loop which
> > will suppress the IO error message.
>
> Setting RQF_QUIET for discard IO should be more clean for suppressing error,
> and upper layer can get the failure notification too.
Hmm, forgot why I didn't do this, did consider it before. Probably because
nobody check the return value of discard request. Probably we should skip the
error message for all discard IO in block layer.
I'll repost a patch to fix this issue.
Thanks,
Shaohua
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH V2 0/3] block/loop: handle discard/zeroout error
@ 2017-09-07 13:20 Ilya Dryomov
2017-09-07 21:54 ` Shaohua Li
0 siblings, 1 reply; 10+ messages in thread
From: Ilya Dryomov @ 2017-09-07 13:20 UTC (permalink / raw)
To: Shaohua Li; +Cc: linux-block, Christoph Hellwig
Hi Shaohua,
You wrote:
> BTW: blkdev_issue_zeroout retries if we immediately find the device doesn't
> support zeroout, but it doesn't retry if submit_bio_wait returns -EOPNOTSUPP.
> Is this correct behavior?
I sent a patch for that yesterday, see "[PATCH] block: cope with WRITE
SAME failing in blkdev_issue_zeroout()" on linux-block. It checks for
-EREMOTEIO, because that's what I hit, but I wonder if it should check
for -EOPNOTSUPP from submit_bio_wait() as well. Can you think of
a case where, given bdev_write_zeroes_sectors() != 0, submit_bio_wait()
would fail with -EOPNOTSUPP and we would want to do explicit zeroing?
Please excuse broken threading.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH V2 0/3] block/loop: handle discard/zeroout error
2017-09-07 13:20 [PATCH V2 0/3] block/loop: handle discard/zeroout error Ilya Dryomov
@ 2017-09-07 21:54 ` Shaohua Li
0 siblings, 0 replies; 10+ messages in thread
From: Shaohua Li @ 2017-09-07 21:54 UTC (permalink / raw)
To: Ilya Dryomov; +Cc: linux-block, Christoph Hellwig
On Thu, Sep 07, 2017 at 03:20:01PM +0200, Ilya Dryomov wrote:
> Hi Shaohua,
>
> You wrote:
> > BTW: blkdev_issue_zeroout retries if we immediately find the device doesn't
> > support zeroout, but it doesn't retry if submit_bio_wait returns -EOPNOTSUPP.
> > Is this correct behavior?
>
> I sent a patch for that yesterday, see "[PATCH] block: cope with WRITE
> SAME failing in blkdev_issue_zeroout()" on linux-block. It checks for
> -EREMOTEIO, because that's what I hit, but I wonder if it should check
> for -EOPNOTSUPP from submit_bio_wait() as well. Can you think of
> a case where, given bdev_write_zeroes_sectors() != 0, submit_bio_wait()
> would fail with -EOPNOTSUPP and we would want to do explicit zeroing?
loop block device returns -EOPNOTSUPP before for zeroout. With the second
patch, it doesn't any more though.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-09-07 21:54 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-09-07 0:13 [PATCH V2 0/3] block/loop: handle discard/zeroout error Shaohua Li
2017-09-07 0:13 ` [PATCH V2 1/3] block/loop: don't hijack error number Shaohua Li
2017-09-07 9:22 ` Ming Lei
2017-09-07 0:13 ` [PATCH V2 2/3] block/loop: use FALLOC_FL_ZERO_RANGE for REQ_OP_WRITE_ZEROES Shaohua Li
2017-09-07 9:05 ` Ming Lei
2017-09-07 0:13 ` [PATCH V2 3/3] block/loop: suppress discard IO error message Shaohua Li
2017-09-07 9:16 ` Ming Lei
2017-09-07 21:52 ` Shaohua Li
-- strict thread matches above, loose matches on Subject: below --
2017-09-07 13:20 [PATCH V2 0/3] block/loop: handle discard/zeroout error Ilya Dryomov
2017-09-07 21:54 ` Shaohua Li
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).