What should be done with udev remove events when the removed device belongs to a running pool?

[mulkieran]

Right now, we observe these remove udev events when they occur on a device that belongs to a stopped pool. However, we do not when they occur on a device that belongs to a running pool.

This occurrence is something of a possibility, and we have availability classifications for pools, etc. that might be used to handle this case.

However, if we did this, we would also have to handle the case for when a device is added to a running pool that did not previously have it.

If a device is removed from a pool, that pool can be stopped. In that case, the missing device is detected during the stopping action. If an attempt is made to start the pool, it can not be, due to the missing device. If the device is re-added, then the pool can be started. One question not asked: after the pool has been restarted, how soon does it update the stale pool-level metadata on the previously removed device?

[jbaublitz]

Just for some context, this was removed because we do not get pool UUID or device UUID on remove events. All we get is path name. We'd have to add some functionality to check whether a file path exists in a pool to be able to do this.