Re: [PATCH V2 2/2] nvmet: add per ns thread to generate AEN

[Sagi Grimberg <sagi@grimberg.me>]

>> But maybe it won't be such a strange thing to dedicate a maintenance
>> thread that would do stuff like this. My main issue with his is that it
>> is polling which to me seems like a band-aid really...
> 
> It is, but having a lightweight maintenance thread is very simple way
> to implement this for bdev and file

Simple at first sight, my main concern is what the impact may be...

> without involving userspace or fancy hacks.

Wouldn't call these hacks really, we have several examples of
disk resize triggering events to usespace.

> What are your concerns about polling (as in sleep() and schedule()
> calls wrt to the code)? Can you please elaborate ?

What is the right polling scheme? what is the impact on the system 
performance? What happens when you have a lot of namespaces?
I view the polling scheme a band-aid resulting for lack of event driven
infrastructure for disk resize.

>>>> I'd suggest to expose a revalidate configfs attribute and have nvmetcli
>>>> install a udev rule that triggers a write to this attribute. Balbir
>>>> already got the udev notification for disk resize (see
>>>> set_capacity_revalidate_and_notify).
>>>
>>> Okay we can do that. So you are saying generate the AEN from configs
>>> attribute.
>>
>> Yes.. that won't work for file backed namespaces though...
>>
> 
> Isn't that defeats the purpose of having a file backend which provides
> more flexibility to the user ?

We could have something that leverages fsnotify to address files...

> I think we should at least try an implementation which has global
> maintenance thread, measure the impact and then discard it before going
> to userspace.

I'm not too fond of the idea in general, but I could be convinced
otherwise. I'm interested to learn what others think.

_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme