Date: Thu, 20 Oct 2011 18:23:57 +0100 From: "Steven Hartland" <killing@multiplay.co.uk> To: <freebsd-stable@freebsd.org> Subject: zfs parition probing causing long delay at BTX loader Message-ID: <441A588158B143D28A1B062A61FCDA43@multiplay.co.uk>
next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. ------=_NextPart_000_0404_01CC8F55.6E820A70 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Installing a new machine here which has 10+ disks we're seeing BTX loader take 50+ seconds to enumerate the disks. After doing some digging I found the following thread on the forums which hinted that r198420 maybe the cause. http://forums.freebsd.org/showthread.php?t=12705 A quick change to zfs.c reverting the change to support 128 partitions back to 4 and BTX completes instantly like it used to. svn commit which introduced this delay is:- http://svnweb.freebsd.org/base?view=revision&revision=198420 the specific file in that changeset:- http://svnweb.freebsd.org/base/head/sys/boot/zfs/zfs.c?r1=198420&r2=198419&pathrev=198420 So the questions are:- 1. Can this be optimised so it doesn't have to test all of the possible 128 GPT partitions? 2. If a optimisation isn't possible or is too complex to achieve would it be better to have the partitions defined as an option which can be increased if needed as I suspect 99.99% if not 100% of users won't be making use of more than 4 partitions even with GPT, such as what the attached patch against 8.2-RELEASE achieves. 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_0404_01CC8F55.6E820A70 Content-Type: text/plain; format=flowed; name="zfs-slice-boot-patch.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zfs-slice-boot-patch.txt" --- 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_0404_01CC8F55.6E820A70--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?441A588158B143D28A1B062A61FCDA43>