Page MenuHomeFreeBSD

vdev_geom_close: close errored consumer even if vdev_reopening is set
ClosedPublic

Authored by avg on Oct 19 2017, 8:53 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Dec 20, 9:59 AM
Unknown Object (File)
Mon, Dec 16, 5:42 PM
Unknown Object (File)
Mon, Dec 2, 10:32 PM
Unknown Object (File)
Mon, Nov 25, 12:55 PM
Unknown Object (File)
Nov 21 2024, 3:35 PM
Unknown Object (File)
Nov 19 2024, 6:57 PM
Unknown Object (File)
Nov 19 2024, 1:38 PM
Unknown Object (File)
Nov 17 2024, 11:24 PM
Subscribers

Details

Summary

If vdev_geom_close doesn't close the consumer, then the subsequent call
to vdev_geom_open() would be just a NOP and would always return success.
Thus, at present vdev_reopen() would always succeed for vdev_geom devices
even if the underlying provider is in error state.
The problem was introduced as a result of an optimization in rS308055.

The most significant manifistation of the problem is that
zio_vdev_io_done() --> vdev_probe() --> SPA_ASYNC_PROBE -->
spa_async_probe() --> vdev_reopen()
chain of calls and events becomes a NOP as well.
This chain is invoked when zio_vdev_io_done() detects an "unexpected"
error from the lower level I/O.
Additionally, that call path may race with SPA_ASYNC_REMOVE path because
of the asynchronous nature of them both. So, the SPA_ASYNC_PROBE may
erroneously mark a vdev as being healthy after SPA_ASYNC_REMOVE marked
it as removed.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable