> Date: Tue, 7 Sep 2021 22:30:45 +0100
> From: Alexander Nasonov
>
> When I run zfs import, it launches 32 threads and opens 32 disks in
> parallel, including cgd1 and dk24. But it can't open dk24 while
> cgd1 is still open (it fails with EBUSY).
I have the attached patch in my tree from a
On Wed, Sep 08, 2021 at 08:51:15AM +0100, Patrick Welche wrote:
> I see something similar in another context: when I shutdown, shutdown
> can stall on a system with dkX on cgdN, with
>
> detaching dkX
> detaching cgdN
> detaching dkX(same X)
> (hang)
>
> If the dice are rolled correctly, and
On Wed, Sep 08, 2021 at 07:57:35AM +0100, Alexander Nasonov wrote:
> The order doesn't have to be arbitrary, the kernel can be fixed
> to return disk names in a well-defined order.
You can do that today with a custom kernel and lots of hard wired
disk attachements (wd0 ... wdN instead of wd*),
On Wed, Sep 08, 2021 at 06:38:02AM -, Michael van Elst wrote:
> al...@yandex.ru (Alexander Nasonov) writes:
>
> >When I run zfs import, it launches 32 threads and opens 32 disks in
> >parallel, including cgd1 and dk24. But it can't open dk24 while
> >cgd1 is still open (it fails with EBUSY).
Michael van Elst wrote:
> There are other issues with scanning devices in an arbitrary order,
> a parallel scan just makes it worse by adding randomness.
The order doesn't have to be arbitrary, the kernel can be fixed
to return disk names in a well-defined order. A new zfs.disknames
sysctl can
al...@yandex.ru (Alexander Nasonov) writes:
>When I run zfs import, it launches 32 threads and opens 32 disks in
>parallel, including cgd1 and dk24. But it can't open dk24 while
>cgd1 is still open (it fails with EBUSY).
>I fixed it in the attatched patch by running only one thread. It's
>not
(forwarding to current-users because tech-misc appears to be inactive)
- Forwarded message from Alexander Nasonov -
Date: Sun, 5 Sep 2021 22:16:48 +0100
From: Alexander Nasonov
To: tech-m...@netbsd.org
Subject: zpool import skips wedges due to a race condition
zfs import reliably
