> "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
8 matches
Mail list logo