On 6/23/21 4:07 PM, Luca Boccassi wrote:
On Wed, 2021-06-23 at 16:01 +0200, Hannes Reinecke wrote:
On 6/23/21 3:51 PM, Lennart Poettering wrote:
On Mi, 23.06.21 15:10, Matteo Croce (mcroce@xxxxxxxxxxxxxxxxxxx) wrote:
On Wed, Jun 23, 2021 at 1:49 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
On Wed, Jun 23, 2021 at 12:58:53PM +0200, Matteo Croce wrote:
+void inc_diskseq(struct gendisk *disk)
+{
+ static atomic64_t diskseq;
Please don't hide file scope variables in functions.
I just didn't want to clobber that file namespace, as that is the only
point where it's used.
Can you explain a little more why we need a global sequence count vs
a per-disk one here?
The point of the whole series is to have an unique sequence number for
all the disks.
Events can arrive to the userspace delayed or out-of-order, so this
helps to correlate events to the disk.
It might seem strange, but there isn't a way to do this yet, so I come
up with a global, monotonically incrementing number.
To extend on this and given an example why the *global* sequence number
matters:
Consider you plug in a USB storage key, and it gets named
/dev/sda. You unplug it, the kernel structures for that device all
disappear. Then you plug in a different USB storage key, and since
it's the only one it will too be called /dev/sda.
With the global sequence number we can still distinguish these two
devices even though otherwise they can look pretty much identical. If
we had per-device counters then this would fall flat because the
counter would be flushed out when the device disappears and when a device
reappears under the same generic name we couldn't assign it a
different sequence number than before.
Thus: a global instead of local sequence number counter is absolutely
*key* for the problem this is supposed to solve
Well ... except that you'll need to keep track of the numbers (otherwise
you wouldn't know if the numbers changed, right?).
And if you keep track of the numbers you probably will have to implement
an uevent listener to get the events in time.
But if you have an uevent listener you will also get the add/remove
events for these devices.
And if you get add and remove events you can as well implement sequence
numbers in your application, seeing that you have all information
allowing you to do so.
So why burden the kernel with it?
Cheers,
Hannes
Hi,
We need this so that we can reliably correlate events to instances of a
device. Events alone cannot solve this problem, because events _are_
the problem.
In which sense?
Yes, events can be delayed (if you list to uevents), but if you listen
to kernel events there shouldn't be a delay, right?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
