From: Bart Van Assche <bvanassche@acm.org>
To: John Pittman <jpittman@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>, linux-block@vger.kernel.org
Subject: Re: [PATCH] null_blk: add zoned config support information
Date: Fri, 04 Jan 2019 12:49:33 -0800 [thread overview]
Message-ID: <1546634973.83374.4.camel@acm.org> (raw)
In-Reply-To: <CA+RJvhyfKrLwFkxAOxqAW=Mthu5HaF_JU6_rgKLjL07uD8TM+g@mail.gmail.com>
On Fri, 2019-01-04 at 15:37 -0500, John Pittman wrote:
> Thanks Bart; I made the changes and sent them in as a v2, I'm sure you
> already saw. I have a quick, unrelated question if you have a moment.
> In testing the null_blk driver, I found that trim commands sent by fio
> were rejected due to lack of support. Tracking down Shaohua's commit
> 306eb6b4a ("nullb: support discard"), he mentions that "discard makes
> sense for memory backed disk". Just to see what would happen, I
> edited the source to make discard a configurable parameter at
> modprobe, and after the edit & build, the trim commands submitted
> fine. Does this sort of change make sense? I mean the ability to do
> discard to null_blk without it being memory backed; solely for
> testing/benchmarking purposes. I haven't found any good instructions
> on creating a memory backed or discard enabled null_blk device from
> the command line, so I assume a higher level driver would have to hook
> in and enable these features manually. Thanks for your time and any
> information.
Hi John,
Jens as the block layer maintainer has the last word about this. Personally
I would welcome that functionality. Before discard functionality was removed
from the brd driver I used the brd driver to test the discard functionality
in storage target stacks. If discard functionality would be added to the
null_blk driver then that would make it possible to use that driver for
testing the discard functionality in e.g. LIO. See also commit f09a06a193d9
("brd: remove discard support").
I'm not sure that we need a modprobe parameter to enable or disable trim
functionality in the null_blk driver. I'm fine with always enabling trim
functionality in that driver.
Bart.
next prev parent reply other threads:[~2019-01-04 20:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-04 15:42 [PATCH] null_blk: add zoned config support information John Pittman
2019-01-04 15:59 ` Laurence Oberman
2019-01-04 16:46 ` Bart Van Assche
2019-01-04 16:58 ` Laurence Oberman
2019-01-04 20:37 ` John Pittman
2019-01-04 20:49 ` Bart Van Assche [this message]
2019-01-04 21:07 ` John Pittman
2019-01-06 19:23 ` Jens Axboe
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=1546634973.83374.4.camel@acm.org \
--to=bvanassche@acm.org \
--cc=axboe@kernel.dk \
--cc=jpittman@redhat.com \
--cc=linux-block@vger.kernel.org \
/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.