[PATCH] null_blk: add zoned config support information

[PATCH] null_blk: add zoned config support information

[John Pittman]

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) {}
-- 
2.17.2

Re: [PATCH] null_blk: add zoned config support information

[Laurence Oberman]

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>

Re: [PATCH] null_blk: add zoned config support information

[Bart Van Assche]

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.

Re: [PATCH] null_blk: add zoned config support information

[Laurence Oberman]

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

Re: [PATCH] null_blk: add zoned config support information

[John Pittman]

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.

Re: [PATCH] null_blk: add zoned config support information

[Bart Van Assche]

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.

Re: [PATCH] null_blk: add zoned config support information

[John Pittman]

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.

Re: [PATCH] null_blk: add zoned config support information

[Jens Axboe]

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.

-- 
Jens Axboe