From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1QEJVe-000891-4Z for mharc-grub-devel@gnu.org; Mon, 25 Apr 2011 06:59:18 -0400 Received: from eggs.gnu.org ([140.186.70.92]:35571) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEJVb-00088v-5K for grub-devel@gnu.org; Mon, 25 Apr 2011 06:59:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QEJVa-00041Q-0K for grub-devel@gnu.org; Mon, 25 Apr 2011 06:59:15 -0400 Received: from mail-wy0-f169.google.com ([74.125.82.169]:64492) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEJVZ-00041M-SL for grub-devel@gnu.org; Mon, 25 Apr 2011 06:59:13 -0400 Received: by wyf19 with SMTP id 19so1867425wyf.0 for ; Mon, 25 Apr 2011 03:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:content-type; bh=/T4frCly1QjgEMtv/SqM1gi9IbMvlyvoKZIVoH4wgiw=; b=ss6MPP5A+LqYDrqYEODMh9SuQPnGzwMEoYsPZR9hzMPCi3hq/DMuFItEItz52QmzjN GwysBXsNVYNQn8MpiRiLvrrZzsjhP/rJ0Tt7yTM0O4bLv99/dW9Aj5HBPHu/kipawJy5 S6wpla3MzYE3UYAtDXcsmhQqcx/1h74byEEw8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=V73G8E+kzgLqbbcI5MNEIz/2zig956ZbuokMye+FgbGgNdB9hUjTTdlEzhX/K8FR2A QWJTdW8j4Dc+d0El4070oSjTIrEq9OFgyaXIpVl+lwsrURirf2RbHykp1Xfp5Vzi/e1K A18oOqRTVF00NXcS2UNDFwDfaxiCo6tD/35CU= Received: by 10.227.10.149 with SMTP id p21mr3716511wbp.195.1303729151013; Mon, 25 Apr 2011 03:59:11 -0700 (PDT) Received: from debian.x201.phnet (78-68.62-81.cust.bluewin.ch [81.62.68.78]) by mx.google.com with ESMTPS id b20sm3208762wbb.16.2011.04.25.03.59.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2011 03:59:09 -0700 (PDT) Message-ID: <4DB553F3.3020503@gmail.com> Date: Mon, 25 Apr 2011 12:58:59 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110402 Iceowl/1.0b2 Icedove/3.1.9 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: Grub2 EFI: Image loading from USB takes too long References: <775884.3554.qm@web120005.mail.ne1.yahoo.com> <4D9F38C9.3090203@gmail.com> <4DA7EBF3.8090007@gmail.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig610B271D7EE79CC2509AA4A6" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 74.125.82.169 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 10:59:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig610B271D7EE79CC2509AA4A6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 25.04.2011 06:14, Bean wrote: > Hi, > > This effects ALL fs since grub_disk_read will break it into 8192 > blocks, regardless of what the upper fs asks. Non-extent based FS simply don't do any direct reads bigger than that unless they implement block pointer buffering and none of our fs does > In burg, I add another > function to read the blocks directly and skip the cache, which results > in much faster reads for large continuous file. Which is an example of bad design. Rather than improving the existing function to do both caching and unbroken read (like in my 4096 branch) you have 2 functions and force upper layers to do the tradeoffs and care about matters which should be abstracted and invisible to them. > 2011/4/15 Vladimir '=CF=86-coder/phcoder' Serbinenko : >> On 15.04.2011 04:45, Bean wrote: >>> Hi, >>> >>> I believe this is caused by the read algorithm of grub2. If the file >>> is continuous, grub legacy will read it in one pass, while grub2 will= >>> break it up into small blocks, this will slow it down dramatically. I= >>> haven't tested efi, but in bios mode, sometimes it takes twice as lon= g >>> for grub2 to read the same file. >>> >> That's why I asked which fs it is. On an FS like ext2 or fat Both GRUB= s >> are limited by the need of rereading indirect blocks or FAT chain (sur= e >> this can be aleviated by buffering and merging the nodes but neither >> GRUB Legacy nor GRUB2 does it). Currently it makes difference only on >> extent-based filesystems like ext, xfs or btrfs. I don't want to embar= k >> on adding another code path in grub_disk_read before having enough inf= o >> to confirm this theory yet neither the original reporter nor the other= s >> answered which FS they conducted experiments on. >> >> -- >> Regards >> Vladimir '=CF=86-coder/phcoder' Serbinenko >> >> >> >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/grub-devel >> >> > > --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig610B271D7EE79CC2509AA4A6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk21U/sACgkQNak7dOguQgkt8gD/eWhVP3xCcQqxwEO9gy61df8p hnfHgTirw1O51UbJqSYBAJTKxV/eDuW8iO9qpMg91fU5F8N0P3hQsSpFCAHPGum/ =IZyH -----END PGP SIGNATURE----- --------------enig610B271D7EE79CC2509AA4A6--