Re: Nullblk configfs oddities

[Chaitanya Kulkarni <chaitanyak@nvidia.com>]

On 4/18/22 15:14, Jens Axboe wrote:
> On 4/18/22 3:54 PM, Chaitanya Kulkarni wrote:
>> On 4/18/22 14:38, Josef Bacik wrote:
>>> Hello,
>>>
>>> I'm trying to add a test to fsperf and it requires the use of nullblk.  I'm
>>> trying to use the configfs thing, and it's doing some odd things.  My basic
>>> reproducer is
>>>
>>> modprobe null_blk
>>> mkdir /sys/kernel/config/nullb/nullb0
>>> echo some shit into the config
>>> echo 1 > /sys/kernel/config/nullb/nullb0/power
>>>
>>> Now null_blk apparently defaults to nr_devices == 1, so it creates nullb0 on
>>> modprobe.  But this doesn't show up in the configfs directory.  There's no way
>>> to find this out until when I try to mkfs my nullb0 and it doesn't work.  The
>>> above steps gets my device created at /dev/nullb1, but there's no actual way to
>>> figure out that's what happened.  If I do something like
>>> /sys/kernel/config/nullb/nullbfsperf I still just get nullb<number>, I don't get
>>> my fancy name.
>>>
>>
>> when you load module with default module parameter it will create a
>> default device with no memory backed mode, that will not be visible in
>> the configfs.
> 
> Right, the problem is really that pre-configured devices (via nr_devices
> being bigger than 0, which is the default) don't show up in configfs.
> That, to me, is the real issue here, because it means you need to know
> which ones are already setup before doing mkdir for a new one.
> 
> On top of that, it's also odd that they don't show up there to begin
> with.
> 

it is indeed confusing, maybe we need to find a way to populate the
configfs when loading the module? but I'm not sure if that is
the right approach since configs ideally should be populated by
user.

OTOH we can make the memory_backed module param [1] so user can
tentatively not use configfs and only rely on default configuration ?


-ck

[1] https://marc.info/?l=linux-block&m=165032010206884&w=2