Long delays during boot and zpool/zfs commands on 9.1-RELEASE (possibly because of unavailable pool?)

[Henner Heck]

Am 15.05.2013 10:42, schrieb Ronald Klop:
> On Tue, 14 May 2013 23:33:08 +0200, Henner Heck <Henner.Heck at web.de>
> wrote:
>
>> Am 14.05.2013 21:22, schrieb Steven Hartland:
>>> ----- Original Message ----- From: "Henner Heck" <Henner.Heck at web.de>
>>>> Hello all,
>>>>
>>>> i set up a PC with FreeBSD 9.1-Release and 2 zfs pools.
>>>> One is a mirror from which FreeBSD is booting
>>>> (tough enough without getting "error 2"),
>>>> the other one a raidz2 for data.
>>>> The disks for the raidz2 are encrypted with geli and attached
>>>> manually.
>>>>
>>>> I noticed that a "zpool status" or a "zfs list" before attaching
>>>> the encrypted disks waits for about one minute before showing output.
>>>> When they finally do, the output is as expected, the raidz2 pool is
>>>> shown as
>>>> UNAVAIL and its datasets are not listed.
>>>> When all the disks are attached with geli, the outputs are given
>>>> immediately.
>>>>
>>>> On boot there are 2 delays.
>>>> One of about 1 minute after the output
>>>> "Setting hostid: 0x........"
>>>> and one of 2 minutes after
>>>> "Mounting local file systems:.".
>>>> Both these outputs don't show up in dmesg, which ends with
>>>> "Trying to mount root from zfs:zroot/ROOT []..." shortly before.
>>>>
>>>> I suspect that the boot delays too are because of the encrypted pool.
>>>>
>>>> A different machine running FreeBSD 8.3-RELEASE has a delay of only
>>>> about 3 seconds on "zpool status" with an encrypted pool
>>>> and also the boot shows no annoying anomalies.
>>>>
>>>> Any idea how to get rid of these really long delays?
>>>
>>> Try the attached patch see if that helps?
>>>
>>>    Regards
>>>    Steve
>>>
>>> ================================================
>>> This e.mail is private and confidential between Multiplay (UK) Ltd.
>>> and the person or entity to whom it is addressed. In the event of
>>> misdirection, the recipient is prohibited from using, copying,
>>> printing or otherwise disseminating it or any information contained in
>>> it.
>>> In the event of misdirection, illegible or incomplete transmission
>>> please telephone +44 845 868 1337
>>> or return the E.mail to postmaster at multiplay.co.uk.
>>
>>
>>
>> Hello Steven,
>>
>> i tried to apply the patch, but patch didn't return and gave no output.
>> I checked my the zfs.c and it doesn't seem to fit this patch.
>> Please see attached file.
>>
>> Regards,
>> Henner Heck
>
> Sounds likes my daily wtf moment. Patch likes the patch-file on stdin.
> That is why it waits forever and does not return. Ctrl-z will help that.
>
> Use something like this:
> patch < foo.diff
>
> Regards,
> Ronald.
>


Always happy to give someone a special moment.
Thank you, now patch did something.
It confirmed that it is the wrong file version for the patch,
since the replacements failed and the only changes are additions.
Output:

----------------------------------------------------------------------------------------------------------
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- sys/boot/zfs/zfs.c.orig    2011-10-20 18:15:29.966685430 +0000
|+++ sys/boot/zfs/zfs.c 2011-10-20 18:18:22.291033636 +0000
--------------------------
Patching file sys/boot/zfs/zfs.c using Plan A...
Hunk #1 succeeded at 47 (offset 2 lines).
Hunk #2 failed at 423.
1 out of 2 hunks failed--saving rejects to sys/boot/zfs/zfs.c.rej
Hmm...  Ignoring the trailing garbage.
done
----------------------------------------------------------------------------------------------------------

I'm still hoping that someone can give the reason for the increased delays.
Since nothing actually goes wrong but just takes ages,
they might have been introduced on purpose,
not considering the possibility of a deliberately unavailable pool.(?)

Regards,
Henner Heck