Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Oct 2011 12:17:54 +0200
From:      Peter Maloney <peter.maloney@brockmann-consult.de>
To:        freebsd-stable@freebsd.org
Subject:   Re: zfs parition probing causing long delay at BTX loader
Message-ID:  <4EA146D2.8070809@brockmann-consult.de>
In-Reply-To: <441A588158B143D28A1B062A61FCDA43@multiplay.co.uk>
References:  <441A588158B143D28A1B062A61FCDA43@multiplay.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
On 10/20/2011 07:23 PM, Steven Hartland wrote:
> Installing a new machine here which has 10+ disks
> we're seeing BTX loader take 50+ seconds to enumerate
> the disks.
I am running 8-STABLE. On my system with 22 disks, it took much longer
than a minute (maybe 5 minutes... not sure, but overall boot was about 7
minutes). While this time is passing, I can watch the leds on the disks
blink in order, many times in a loop.

My IO card is a LSI SATA/SAS 9211-8i 6Gb/s.

After I upgraded the firmware to version 11, it seems to take much less
time, but I didn't time it. And watching the LEDs last time I rebooted,
I don't notice them all blinking the same way. Instead, all were solid
for a second or two after the long wait, and then only the root disks.

So if you have the same card, I suggest you update the firmware. (I
updated for stability rather than boot speed, and it seemed stable until
it froze today, after 2 weeks)

> 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.
>
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EA146D2.8070809>