On 6/23/21 4:12 PM, Lennart Poettering wrote:
On Mi, 23.06.21 16:01, Hannes Reinecke (hare@xxxxxxx) wrote:
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.
Hmm? This is backwards. The goal here is to be able to safely match up
uevents to specific uses of a block device, given that block device
names are agressively recycled.
you imply it was easy to know which device use a uevent belongs
to. But that's the problem: it is not possible to do so safely. if i
see a uevent for a block device "loop0" I cannot tell if it was from
my own use of the device or for some previous user of it.
And that's what we'd like to see fixed: i.e. we query the block device
for the seqeno now used and then we can use that to filter the uevents
and ignore the ones that do not carry the same sequence number as we
got assigned for our user.
It is notoriously tricky to monitor the intended use-case for kernel
devices, precisely because we do _not_ attach any additional information
to it.
I have send a proposal for LSF to implement block-namespaces, the prime
use-case of which is indeed attaching cgroup/namespace information to
block devices such that we _can_ match (block) devices to specific contexts.
Which I rather prefer than adding sequence numbers to block devices;
incidentally you could solve the same problem by _not_ reusing numbers
aggressively but rather allocate the next free one after the most
recently allocated one.
Will give you much the same thing without having to burden others with it.
The better alternative here would be to extend the loop ioctl to pass in
an UUID when allocating the device.
That way you can easily figure out whether the loop device has been
modified.
But in the end, it's the loop driver and I'm not particular bothered
with it. I am, though, if you need to touch all drivers just to support
one particular use-case in one particular device driver.
Incidentally, we don't have this problem in SCSI as we _can_ identify
devices here. So in the end we couldn't care less on which /dev/sdX
device it ends up.
And I guess that's what we should attempt for loop devices, too.
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
