misc/161897: zfs parition probing causing long delay at BTX loader

Steven Hartland steven.hartland at FreeBSD.org
Sat Oct 22 13:10:10 UTC 2011


>Number:         161897
>Category:       misc
>Synopsis:       zfs parition probing causing long delay at BTX loader
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Oct 22 13:10:09 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:     Steven Hartland
>Release:        8.2-RELEASE
>Organization:
Multiplay
>Environment:
FreeBSD loncore0.multiplay.co.uk 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Fri Mar 18 10:58:44 UTC 2011     root at bigcore0.multiplay.co.uk:/usr/obj/usr/src/sys/MULTIPLAY  amd64
>Description:
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.

>How-To-Repeat:
Boot a machine with a large number of disks attached using zfs
>Fix:
Reduce the number of probed partitions from the GPT max of 128 back to the MBR max of 4 "by default" as done by the attached patch.

Patch attached with submission follows:

--- 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
@@ -45,6 +45,12 @@
 
 #include "zfsimpl.c"
 
+/*
+ * For GPT this should be 128 but leads to 50+ second delay in BTX loader so
+ * we use the original 4 pre r198420 by default for the boot process
+ */
+#define ZFS_MAX_SLICES 4
+
 static int	zfs_open(const char *path, struct open_file *f);
 static int	zfs_write(struct open_file *f, void *buf, size_t size, size_t *resid);
 static int	zfs_close(struct open_file *f);
@@ -415,7 +421,7 @@
 		if (vdev_probe(vdev_read, (void*) (uintptr_t) fd, 0))
 			close(fd);
 
-		for (slice = 1; slice <= 128; slice++) {
+		for (slice = 1; slice <= ZFS_MAX_SLICES; slice++) {
 			sprintf(devname, "disk%dp%d:", unit, slice);
 			fd = open(devname, O_RDONLY);
 			if (fd == -1) {


>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list