All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Bart Van Assche <bart.vanassche@sandisk.com>,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, dm-devel@redhat.com,
	"Alasdair G. Kergon" <agk@redhat.com>,
	Mike Snitzer <snitzer@redhat.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>
Subject: Re: REQ_OP for zeroing, was Re: [dm-devel] [PATCH 1/4] brd: handle misaligned discard
Date: Mon, 31 Oct 2016 12:36:16 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LRH.2.02.1610311233550.27707@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <20161028131457.GA15656@infradead.org>



On Fri, 28 Oct 2016, Christoph Hellwig wrote:

> [adding Chaitanya to Cc]
> 
> On Fri, Oct 28, 2016 at 07:43:41AM -0400, Mikulas Patocka wrote:
> > We could detect if the REQ_OP_WRITE_SAME command contains all zeroes and 
> > if it does, turn it into "Write Zeroes" or TRIM command (if the device 
> > guarantees zeroing on trim). If it doesn't contain all zeroes and the 
> > device doesn't support non-zero WRITE SAME, then reject it.
> 
> I don't like this because it's very inefficient - we have to allocate
> a payload first and then compare the whole payload for very operation.
> 
> > Or maybe we could add a new command REQ_OP_WRITE_ZEROES - I'm not sure 
> > which of these two possibilities is better.
> 
> Chaitanya actually did an initial prototype implementation of this for
> NVMe that he shared with me.  I liked it a lot and I think he'll be
> ready to post it in a few days.  Now that we have the REQ_OP* values
> instead of mapping different command types to flags it's actually
> surprisingly easy to add new block layer operations.

OK - when it is in the kernel, let me know, so that I can write device 
mapper support for that.

We should remove the flag "discard_zeroes_data" afterwards, because it is 
unreliable and impossible to support correctly in the device mapper.

Mikulas

  reply	other threads:[~2016-10-31 16:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-21 18:33 device mapper and the BLKFLSBUF ioctl Mikulas Patocka
2016-10-21 20:00 ` Mike Snitzer
2016-10-21 20:18   ` Mikulas Patocka
2016-10-24 15:57     ` Mike Snitzer
2016-10-25 13:07       ` Christoph Hellwig
2016-10-25 14:37         ` [PATCH] brd: remove support for BLKFLSBUF Mike Snitzer
2016-10-25 14:46           ` Jens Axboe
2016-10-26 20:25             ` [PATCH 0/4] brd: support discard Mikulas Patocka
2016-10-26 20:26               ` [PATCH 1/4] brd: handle misaligned discard Mikulas Patocka
2016-10-26 20:38                 ` [dm-devel] " Bart Van Assche
2016-10-26 20:38                   ` Bart Van Assche
2016-10-26 21:46                   ` Mikulas Patocka
2016-10-26 21:50                     ` REQ_OP for zeroing, was " Christoph Hellwig
2016-10-28 11:43                       ` Mikulas Patocka
2016-10-28 13:14                         ` Christoph Hellwig
2016-10-31 16:36                           ` Mikulas Patocka [this message]
2016-10-26 21:57                     ` Bart Van Assche
2016-10-26 21:57                       ` Bart Van Assche
2016-10-28 11:39                       ` Mikulas Patocka
2016-10-28 15:55                         ` Bart Van Assche
2016-10-28 15:55                           ` Bart Van Assche
2016-10-31 16:31                           ` Mikulas Patocka
2016-10-26 20:26               ` [PATCH 2/4] brd: extend rcu read sections Mikulas Patocka
2016-10-26 20:27               ` [PATCH 3/4] brd: implement discard Mikulas Patocka
2016-10-26 20:27               ` [PATCH 4/4] brd: remove unused brd_zero_page Mikulas Patocka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LRH.2.02.1610311233550.27707@file01.intranet.prod.int.rdu2.redhat.com \
    --to=mpatocka@redhat.com \
    --cc=Chaitanya.Kulkarni@wdc.com \
    --cc=agk@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=bart.vanassche@sandisk.com \
    --cc=dm-devel@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=snitzer@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.