Date: Tue, 14 May 2013 20:22:39 +0100 From: "Steven Hartland" <killing@multiplay.co.uk> To: "Henner Heck" <Henner.Heck@web.de>, <freebsd-fs@freebsd.org> Subject: Re: Long delays during boot and zpool/zfs commands on 9.1-RELEASE (possibly because of unavailable pool?) Message-ID: <A6A43A3F71994DC68F4F51124FA213E5@multiplay.co.uk> References: <968416157.282645.1368232366317.JavaMail.root@erie.cs.uoguelph.ca> <518EFE05.8010100@hub.org> <518F4130.6080201@hub.org> <518F4307.3060908@hub.org> <519285C9.8000306@web.de>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
------=_NextPart_000_09AF_01CE50E0.C7C3AFF0
Content-Type: text/plain;
format=flowed;
charset="iso-8859-1";
reply-type=original
Content-Transfer-Encoding: 7bit
----- Original Message -----
From: "Henner Heck" <Henner.Heck@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@multiplay.co.uk.
------=_NextPart_000_09AF_01CE50E0.C7C3AFF0
Content-Type: application/octet-stream;
name="zfs-slice-boot.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="zfs-slice-boot.patch"
--- sys/boot/zfs/zfs.c.orig 2011-10-20 18:15:29.966685430 +0000=0A=
+++ sys/boot/zfs/zfs.c 2011-10-20 18:18:22.291033636 +0000=0A=
@@ -45,6 +45,12 @@=0A=
=0A=
#include "zfsimpl.c"=0A=
=0A=
+/*=0A=
+ * For GPT this should be 128 but leads to 50+ second delay in BTX =
loader so=0A=
+ * we use the original 4 pre r198420 by default for the boot process=0A=
+ */=0A=
+#define ZFS_MAX_SLICES 4=0A=
+=0A=
static int zfs_open(const char *path, struct open_file *f);=0A=
static int zfs_write(struct open_file *f, void *buf, size_t size, =
size_t *resid);=0A=
static int zfs_close(struct open_file *f);=0A=
@@ -415,7 +421,7 @@=0A=
if (vdev_probe(vdev_read, (void*) (uintptr_t) fd, 0))=0A=
close(fd);=0A=
=0A=
- for (slice =3D 1; slice <=3D 128; slice++) {=0A=
+ for (slice =3D 1; slice <=3D ZFS_MAX_SLICES; slice++) {=0A=
sprintf(devname, "disk%dp%d:", unit, slice);=0A=
fd =3D open(devname, O_RDONLY);=0A=
if (fd =3D=3D -1) {=0A=
------=_NextPart_000_09AF_01CE50E0.C7C3AFF0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A6A43A3F71994DC68F4F51124FA213E5>