On Thu, 2024-10-31 at 14:32 -0400, Benjamin Marzinski wrote: > This patchset include a couple of miscellaneous cleanups, but is > mostly > in response to issues brought up in > https://github.com/opensvc/multipath-tools/issues/100 > It adds auto restarting to the multipathd.service unit file. I'm > fairly > conflicted about the correct limits to be placed on these restarts, > so > if anyone has strong opinions and a good argument, I'm more than > willing > to change them. > > The bulk of the changes deal with how multipath handles devices > without > any table. Multipath was supposed to delete these if they were left > behind after a failed device creation, but that code was broken. > However devices aren't typically left behind after failed creates, so > it > didn't matter. > > A bigger issue is that multipathd and multipath could fail if > tableless > devices were present. With this patchset, they will simply ignore > tableless devices that don't have a multipath prefixed DM UUID. The > last > patch is a RFC patch that changes the behavior for tableless devices > that do have a multipath prefixed DM UUID. It makes multipath remove > these devices on the grounds that they are likely failed creates. > However, looking at the libdevmapper code, I'm not sure that we > actually > want to do this. When a DM_DEVICE_CREATE task is run, it will first > create a tableless device, and then immediately load the table and > resume the device. So it's possible any that tableless devices which > multipath sees are actually in the process of getting created. I left > the patch as part of the set, but I'm not sure that removing the > devices > is the right answer here. I haven't ever seen any tableless multipath > devices lying around (and I couldn't force any to get created when I > tried). Unless other people have seen these, then I don't think the > final patch of this set should go in. > Does it do any harm if we just keep these devices around? If there are path devices around with matching UUIDs, the right thing to do for multipathd would be to reload the map's table with an appropriate multipath target. Otherwise, the map will just float around empty and do no harm. This is how multipathd 0.9.9 and earlier behave, and I see no issue with that. It'd be much worse if someone created a table with an mpath-style UUID and name but an incompatible immutable target type. But in that case, again, we should probably just keep our hands off that map. Martin
