On Tue, Jun 07, 2016 at 07:58:25AM -0700, Shaohua Li wrote:
>
> I didn't follow. io_err is only and always set when ret == 0. io_err is
> meanless if ret != 0, because that means the disk doesn't support discard and
> we don't dispatch discard IO. why should we initialized io_err to 0?
My mistake
On Tue, Jun 14, 2016 at 10:14:50PM -0400, Martin K. Petersen wrote:
> > "Christoph" == Christoph Hellwig writes:
>
> Christoph> And I'd much prefer to get this right now. It's not like
> Christoph> this is recently introduced behavior.
>
> Unfortunately there are quite a few callers of blkd
On Tue, Jun 14 2016 at 10:30pm -0400,
Martin K. Petersen wrote:
> > "Mike" == Mike Snitzer writes:
>
> Mike,
>
> Mike> so long story short: making this change to remove this so-called
> Mike> "stupid behaviour" will require code like
> Mike> drivers/md/dm-thin.c:issue_discard(() to check t
> "Mike" == Mike Snitzer writes:
Mike,
Mike> so long story short: making this change to remove this so-called
Mike> "stupid behaviour" will require code like
Mike> drivers/md/dm-thin.c:issue_discard(() to check the return from
Mike> __blkdev_issue_discard() and if it is -EOPNOTSUPP then it s
> "Christoph" == Christoph Hellwig writes:
Christoph> We can move the sanity checks out. Or even better get rid of
Christoph> the stupid behavior of ignoring the late -EOPNOTSUPP in this
Christoph> low level helper and instead leaving it to the caller(s) that
Christoph> care.
It definitely
On Mon, Jun 13 2016 at 4:20am -0400,
Christoph Hellwig wrote:
> On Fri, Jun 10, 2016 at 09:49:44PM -0400, Martin K. Petersen wrote:
> > >> What does the extra io_err buy us? Just have this function return an
> > >> error. And then in blkdev_issue_discard if you get -EOPNOTSUPP you
> > >> special
On Fri, Jun 10, 2016 at 09:49:44PM -0400, Martin K. Petersen wrote:
> >> What does the extra io_err buy us? Just have this function return an
> >> error. And then in blkdev_issue_discard if you get -EOPNOTSUPP you
> >> special case it there.
>
> Shaohua> The __blkdev_issue_discard returns -EOPNOTS
> "Shaohua" == Shaohua Li writes:
Shaohua,
>> What does the extra io_err buy us? Just have this function return an
>> error. And then in blkdev_issue_discard if you get -EOPNOTSUPP you
>> special case it there.
Shaohua> The __blkdev_issue_discard returns -EOPNOTSUPP if disk doesn't
Shaohua>
On Thu, Jun 09, 2016 at 10:04:08PM -0400, Martin K. Petersen wrote:
> > "Shaohua" == Shaohua Li writes:
>
> Shaohua,
>
> diff --git a/block/blk-lib.c b/block/blk-lib.c
> index 23d7f30..a3a26c8 100644
> --- a/block/blk-lib.c
> +++ b/block/blk-lib.c
> @@ -84,6 +84,28 @@ int __blkdev_issue_disc
> "Christoph" == Christoph Hellwig writes:
>> Userland apps rely on EOPNOTSUPP, we can't break that.
Christoph> Rely on what exactly? Current we return EOPNOTSUPP if the
Christoph> device doesn't claim to support discards, but it returns 0 if
Christoph> the device first claims to support it
> "Shaohua" == Shaohua Li writes:
Shaohua,
diff --git a/block/blk-lib.c b/block/blk-lib.c
index 23d7f30..a3a26c8 100644
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@ -84,6 +84,28 @@ int __blkdev_issue_discard(struct block_device *bdev,
sector_t sector,
}
EXPORT_SYMBOL(__blkdev_issue_disc
On Tue, Jun 07, 2016 at 05:50:49AM +0100, Sitsofe Wheeler wrote:
> On Mon, Jun 06, 2016 at 03:33:58PM -0700, Shaohua Li wrote:
> > blkdev_issue_zeroout try discard/writesame first, if they fail, zeroout
> > fallback to regular write. The problem is discard/writesame doesn't
> > return error for -EO
On Mon, Jun 06, 2016 at 10:32:38PM -0400, Martin K. Petersen wrote:
> > "Mike" == Mike Snitzer writes:
>
> Mike> But hch was originally in favor of _always_ dropping EOPNOTSUPP on
> Mike> the floor (that is what his commit 38f25255330 did). Then he said
> Mike> he disagrees with these interf
On Mon, Jun 06, 2016 at 03:33:58PM -0700, Shaohua Li wrote:
> blkdev_issue_zeroout try discard/writesame first, if they fail, zeroout
> fallback to regular write. The problem is discard/writesame doesn't
> return error for -EOPNOTSUPP, then zeroout can't do fallback and leave
> disk data not change
> "Mike" == Mike Snitzer writes:
Mike> But hch was originally in favor of _always_ dropping EOPNOTSUPP on
Mike> the floor (that is what his commit 38f25255330 did). Then he said
Mike> he disagrees with these interfaces playing games with masking
Mike> EOPNOTSUPP -- to which you seemingly rea
blkdev_issue_zeroout try discard/writesame first, if they fail, zeroout
fallback to regular write. The problem is discard/writesame doesn't
return error for -EOPNOTSUPP, then zeroout can't do fallback and leave
disk data not changed. zeroout should have guaranteed zero-fill
behavior.
https://bugzi
On Thu, Jun 02 2016 at 11:06pm -0400,
Martin K. Petersen wrote:
> > "Christoph" == Christoph Hellwig writes:
>
> Christoph> As part of that I also removed the strange EOPNOTSUPP ignore,
> Christoph> but Mike reverted it just because it changed something in the
> Christoph> dm testsuite.
>
> "Shaohua" == Shaohua Li writes:
Shaohua> blkdev_issue_zeroout try discard/writesame first, if they fail,
Shaohua> zeroout fallback to regular write. The problem is
Shaohua> discard/writesame doesn't return error for -EOPNOTSUPP, then
Shaohua> zeroout can't do fallback and leave disk data no
> "Christoph" == Christoph Hellwig writes:
Christoph> As part of that I also removed the strange EOPNOTSUPP ignore,
Christoph> but Mike reverted it just because it changed something in the
Christoph> dm testsuite.
Mike?
Christoph> I still believe we should never ignore it in this helper, an
> "Sitsofe" == Sitsofe Wheeler writes:
Sitsofe> The original SCSI WRITE SAME has overloaded semantics - not
Sitsofe> only does it mean "write this data multiple times" but it can
Sitsofe> also be used to mean "discard this range" too. If the kernel's
Sitsofe> command was modelled on the SCSI
> "Shaohua" == Shaohua Li writes:
Shaohua> any chance you could merge this one? I'll fix the MD part later
Shaohua> and make sure write_same_max_bytes sets to 0 after IO failure.
I'd like to look it over first. I've been away for a few days. Will get
to it today.
--
Martin K. Petersen
On Sat, May 28, 2016 at 10:27:55AM +0100, Sitsofe Wheeler wrote:
> On Sat, May 28, 2016 at 08:55:43AM +, Sitsofe Wheeler wrote:
> > On Thu, May 26, 2016 at 11:08:14AM -0700, Shaohua Li wrote:
> > > blkdev_issue_zeroout try discard/writesame first, if they fail, zeroout
> > > fallback to regular
On Thu, May 26, 2016 at 11:08:14AM -0700, Shaohua Li wrote:
> -int blkdev_issue_discard(struct block_device *bdev, sector_t sector,
> - sector_t nr_sects, gfp_t gfp_mask, unsigned long flags)
> +static int do_blkdev_issue_discard(struct block_device *bdev, sector_t
> sector,
We've spl
On Sat, May 28, 2016 at 08:55:43AM +, Sitsofe Wheeler wrote:
> On Thu, May 26, 2016 at 11:08:14AM -0700, Shaohua Li wrote:
> > blkdev_issue_zeroout try discard/writesame first, if they fail, zeroout
> > fallback to regular write. The problem is discard/writesame doesn't
> > return error for -EO
blkdev_issue_zeroout try discard/writesame first, if they fail, zeroout
fallback to regular write. The problem is discard/writesame doesn't
return error for -EOPNOTSUPP, then zeroout can't do fallback and leave
disk data not changed. zeroout should have guaranteed zero-fill
behavior.
BTW, I saw se
25 matches
Mail list logo
