@ahrens Have you had time to take a deeper look at latest changes ?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/424#issuecomment-337288816
On 17/10/2017 19:05, George Wilson wrote:
> Andriy,
>
> I'm not familiar with spa_async_thread_vd() (I don't believe that is
> upstreamed
> yet) so I can't comment on what is the correct thing to do there.
Oh, I didn't realize that that part of the code was FreeBSD only.
Alexander made the
Andriy,
I'm not familiar with spa_async_thread_vd() (I don't believe that is
upstreamed yet) so I can't comment on what is the correct thing to do
there. As for spa_async_thread(), I think we can ignore all tasks when the
pool is read-only. You'll probably need to update the call to vdev_probe()
Both spa_async_thread() and spa_async_thread_vd() assert that spa_sync_on is
true. I think that the logic to ensure that is sound except for one case.
Specifically, if a pool is imported read-only, then spa_sync_on is never set to
true (which is correct), but spa_async_suspended is not
Does anyone know a reason for this assertion in annotate_ecksum() ?
ASSERT3U(nui64s, <=, UINT16_MAX);
where nui64s = size / sizeof (uint64_t) with size being the size of the
corrupted block. I looked at the code but could not find any obvious reason for
the limit.
I think that with
