On Mo, 15.03.21 20:18, Matthew Wilcox (willy@xxxxxxxxxxxxx) wrote: 65;6203;1c > On Mon, Mar 15, 2021 at 09:02:38PM +0100, Matteo Croce wrote: > > From: Matteo Croce <mcroce@xxxxxxxxxxxxx> > > > > Add a sequence number to the disk devices. This number is put in the > > uevent so userspace can correlate events when a driver reuses a device, > > like the loop one. > > Should this be documented as monotonically increasing? I think this would be great. My usecase for this would be to match up uevents with loopback block device attachments, because that's basically impossible right now: you attach a loopback device to a file, and then wait for the relevant uevents to happen, for all partitions but you cannot do this safely right now, since loopback block devices are heavily reused in many scenarios so you never know if a uevent is from the attachment you created yourself or from a previous one — or even already for the next. If this would be documented as being monotonic this would be excellent for this usecase: if you know that your own use of a specific loopback device got seqno x then you know that if you see uevents for seqno < x it makes sense to wait longer, but when you see seqno > x then you know it's too late, somehow you lost uevents and hsould abort. Hence: for my usecase having this strictly monotonic, and thus being able to *order* attachments across all areas where the seqno appears would be absolutely excellent and make this as robust as it possibly could be. > I think this is actually a media identifier. Consider (if you will) > a floppy disc. Back when such things were common, it was possible > with personal computers of the era to have multiple floppy discs "in > play" and be prompted to insert them as needed. So shouldn't it be > possible to support something similar here -- you're really removing > the media from the loop device. With a monotonically increasing > number, you're always destroying the media when you remove it, but > in principle, it should be possible to reinsert the same media and > have the same media identifier number. This would be useless for my usecase, we don't really care for the precise file being attached (which is queriable via sysfs anyway), but we want to match up our use of the device with the uevents it generates on itself and decendend partition block devices. Hence: for my usecase I want something that recognizes *attachments* and not media. If i attach the same media 3 times i want to be able to discern the three times. And more importantly: if I attach it once and someone else also once, then I don't want to get confused by that and be able ti distinguish both attachments. Morevoer, I am not even sure what media identifier would mean: if you have one image and then copy it, is that still the same image? in your model, should that have distinct ids? or the same, because it is from the same common original version? and if i then modify one, what happens then? Finally, media usually comes with ids anyway. i.e. file systems have uuids, GPT partition tables have meda uuids. The infrastructure for that already exists. What we need really is something that allows us to track attachments, not media. (That said, I think it would make sense to bump the IDs not only on explicit user-induced reattachments, but also when media is replaced, i.e. bump it more often than not) Lennart -- Lennart Poettering, Berlin
