Re: Grub2 EFI: Image loading from USB takes too long

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]

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 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>> 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 long
>>> for grub2 to read the same file.
>>>
>> That's why I asked which fs it is. On an FS like ext2 or fat Both GRUBs
>> are limited by the need of rereading indirect blocks or FAT chain (sure
>> 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 embark
>> on adding another code path in grub_disk_read before having enough info
>> to confirm this theory yet neither the original reporter nor the others
>> answered which FS they conducted experiments on.
>>
>> --
>> Regards
>> Vladimir 'φ-coder/phcoder' Serbinenko
>>
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>>
>
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]