[RFC] Few patches about suspended pools

[Alexander Motin]

Hoping somebody reads this, here is some addition.

On 26.07.2013 12:40, Alexander Motin wrote:
> I would like to request for some comments about few patches I've made to
> improve handling of pools that lost devices, becoming incomplete and
> suspended: http://people.freebsd.org/~mav/zfs_patches/.
>
>   cmd_on_suspend.patch -- allows three IOCTLs to be used on suspended
> pool. Looking on SVN log, this patch should restore the state of things
> we had up to some code drop from illumos, that seems also imported their
> issues. This change allows `zpool clear` to be used to recover suspended
> pool, `zpool status -v` print list of errors for the suspended pool, the
> third IOCTL looks like some name resolution not very clear to me, but
> that doesn't look like obviously suspend-related.
>
>   remove_last.patch -- makes SPA_ASYNC_REMOVE async events in ZFS to be
> processed even after pool was suspended. Without that, async events are
> handled only after successful txg commit, that is obviously impossible
> without disks. In fact patch makes async thread to be called immediately
> on SPA_ASYNC_REMOVE async events. I haven't found any reason why async
> events (especially this) should be handled only once per commit.

I've found that calling async event in arbitrary time increases always 
existing chances to get stuck with attempt to get configuration write 
lock while some read lock holder blocked infinitely waiting for I/O, 
blocking zpool completely. So I've rewritten this patch to handle 
SPA_ASYNC_REMOVE in separate thread since it is more critical for the 
whole system behavior and same time does not require configuration lock: 
remove_last2.patch

>   online_on_suspend.patch -- is somewhat questionable and possibly
> incomplete patch. The idea was to make `zpool online` command work for
> suspended pools, as some sources recommend. The problem is that this
> command tries to change pool content (like updating history) or wait for
> completion. That required some hacks to make it not stuck with pool
> still suspended.


Also I've found a way to hang ZFS by device detach up to the state of 
freezing `zpool status`. Issue was introduced with pool features 
implementation. `zpool` tool reads pool configuration on every pool 
opening. Previously there was no problem since the configuration was 
recreated by kernel from data that seems always present in memory. But 
newly introduced feature use counters may not. They are stored in ZAP 
and in normal case just live in ARC. But if system has strong ARC 
pressure, that information may be evicted, and then. if we are loosing 
devices, we are stuck. I am not sure what would be a proper fix for this 
situation. I've created workaround (no_features.patch) that blocks 
features reporting to user-level if pool is suspended. That is a bit 
overkill, but helps with one predictable flaw: `zpool upgrade` always 
wish to upgrade suspended pools, but fortunately it can't due to the 
same suspension.

-- 
Alexander Motin