| Message ID | 20190104154243.3538-1-jpittman@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | null_blk: add zoned config support information | expand |
On Fri, 2019-01-04 at 10:42 -0500, John Pittman wrote: > If the kernel is built without CONFIG_BLK_DEV_ZONED, a modprobe > of the null_blk driver with zoned=1 fails with 'Invalid argument'. > This can be confusing to users, prompting a search as to why the > parameter is invalid. To assist in that search, add a bit more > information to the failure, additionally adding to the documentation > that CONFIG_BLK_DEV_ZONED is needed for zoned=1. > > Signed-off-by: John Pittman <jpittman@redhat.com> > --- > Documentation/block/null_blk.txt | 3 ++- > drivers/block/null_blk.h | 1 + > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/block/null_blk.txt > b/Documentation/block/null_blk.txt > index ea2dafe49ae8..4cad1024fff7 100644 > --- a/Documentation/block/null_blk.txt > +++ b/Documentation/block/null_blk.txt > @@ -88,7 +88,8 @@ shared_tags=[0/1]: Default: 0 > > zoned=[0/1]: Default: 0 > 0: Block device is exposed as a random-access block device. > - 1: Block device is exposed as a host-managed zoned block device. > + 1: Block device is exposed as a host-managed zoned block device. > Requires > + CONFIG_BLK_DEV_ZONED. > > zone_size=[MB]: Default: 256 > Per zone size when exposed as a zoned block device. Must be a > power of two. > diff --git a/drivers/block/null_blk.h b/drivers/block/null_blk.h > index b3df2793e7cd..cab4808f14bd 100644 > --- a/drivers/block/null_blk.h > +++ b/drivers/block/null_blk.h > @@ -97,6 +97,7 @@ void null_zone_reset(struct nullb_cmd *cmd, > sector_t sector); > #else > static inline int null_zone_init(struct nullb_device *dev) > { > + pr_info("CONFIG_BLK_DEV_ZONED not enabled\n"); > return -EINVAL; > } > static inline void null_zone_exit(struct nullb_device *dev) {} Looks good to me, useful change in my opinion. Reviewed-by: Laurence Oberman <loberman@redhat.com>
On Fri, 2019-01-04 at 10:42 -0500, John Pittman wrote: > static inline int null_zone_init(struct nullb_device *dev) > { > + pr_info("CONFIG_BLK_DEV_ZONED not enabled\n"); > return -EINVAL; > } Have you considered to use pr_err() instead of pr_info()? Thanks, Bart.
On Fri, 2019-01-04 at 08:46 -0800, Bart Van Assche wrote: > On Fri, 2019-01-04 at 10:42 -0500, John Pittman wrote: > > static inline int null_zone_init(struct nullb_device *dev) > > { > > + pr_info("CONFIG_BLK_DEV_ZONED not enabled\n"); > > return -EINVAL; > > } > > Have you considered to use pr_err() instead of pr_info()? > > Thanks, > > Bart. Bart, good point, Thank you Laurence
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.
John
On Fri, Jan 4, 2019 at 11:47 AM Bart Van Assche <bvanassche@acm.org> wrote:
>
> On Fri, 2019-01-04 at 10:42 -0500, John Pittman wrote:
> > static inline int null_zone_init(struct nullb_device *dev)
> > {
> > + pr_info("CONFIG_BLK_DEV_ZONED not enabled\n");
> > return -EINVAL;
> > }
>
> Have you considered to use pr_err() instead of pr_info()?
>
> Thanks,
>
> Bart.
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.
Thanks Bart, I appreciate it. On Fri, Jan 4, 2019 at 3:49 PM Bart Van Assche <bvanassche@acm.org> wrote: > > 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.
On 1/4/19 1:37 PM, 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. I think that would be fine, no option needed. It's really no different than reads/writes being completed without having a memory backing.
diff --git a/Documentation/block/null_blk.txt b/Documentation/block/null_blk.txt index ea2dafe49ae8..4cad1024fff7 100644 --- a/Documentation/block/null_blk.txt +++ b/Documentation/block/null_blk.txt @@ -88,7 +88,8 @@ shared_tags=[0/1]: Default: 0 zoned=[0/1]: Default: 0 0: Block device is exposed as a random-access block device. - 1: Block device is exposed as a host-managed zoned block device. + 1: Block device is exposed as a host-managed zoned block device. Requires + CONFIG_BLK_DEV_ZONED. zone_size=[MB]: Default: 256 Per zone size when exposed as a zoned block device. Must be a power of two. diff --git a/drivers/block/null_blk.h b/drivers/block/null_blk.h index b3df2793e7cd..cab4808f14bd 100644 --- a/drivers/block/null_blk.h +++ b/drivers/block/null_blk.h @@ -97,6 +97,7 @@ void null_zone_reset(struct nullb_cmd *cmd, sector_t sector); #else static inline int null_zone_init(struct nullb_device *dev) { + pr_info("CONFIG_BLK_DEV_ZONED not enabled\n"); return -EINVAL; } static inline void null_zone_exit(struct nullb_device *dev) {}
If the kernel is built without CONFIG_BLK_DEV_ZONED, a modprobe of the null_blk driver with zoned=1 fails with 'Invalid argument'. This can be confusing to users, prompting a search as to why the parameter is invalid. To assist in that search, add a bit more information to the failure, additionally adding to the documentation that CONFIG_BLK_DEV_ZONED is needed for zoned=1. Signed-off-by: John Pittman <jpittman@redhat.com> --- Documentation/block/null_blk.txt | 3 ++- drivers/block/null_blk.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-)