grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] zfs module update


From: Toomas Soome
Subject: Re: [PATCH] zfs module update
Date: Tue, 14 Apr 2015 08:53:32 +0300

> On 14.04.2015, at 7:34, Andrei Borzenkov <address@hidden> wrote:
> 
> В Tue, 14 Apr 2015 02:17:43 +0300
> Toomas Soome <address@hidden> пишет:
> 
>> hi!
>> 
>> this is the major update to grub2 zfs module; the work is based on Oracle 
>> code drops from Solaris 11, and Illumos.
> 
> IANAL but I suspect such changes require at least submission from
> someone with Oracle E-Mail
> 
> + *  Copyright (c) 2010, 2012, Oracle and/or its affiliates. All rights 
> reserved

the oracle related bits are from:
http://www.oracle.com/technetwork/opensource/systems-solaris-1562786.html

which states clearly: 
"The source code for open source software and firmware components, as licensed 
under the applicable open source licenses, may be found by following the links 
below.”

And grub code has open source license and is included in links provided by this 
page. Therefore I see no problem using this published source just as well as 
grub is using for example, the libgcrypt from gnupg  or using bits from illumos 
- which is just as open source as grub. The copyright lines added by Oracle are 
preserved, just as well as for other entities who have contributed updates to 
openzfs.


> 
>> I am including here two separate patch sets, first is zfs itself, second one 
>> is update to allow embedding.
>> 
>> supports:
>> - all current OpenZFS features
>> - Solaris 11 zpool versions (including reading encrypted datasets)
>> - can recognise and boot all pool configurations with exception that log 
>> device is not inspected (thats something to be investigated in future, while 
>> this code does not mind log device, its still probably not good idea to 
>> actually have one).
>> - pool is readable as long as there is enough parity to reconstruct data from
>> - supports multiple vdevs
>> - supports both mirror and raidz
>> - supports bootloader embedding as long as it will fit to 3.5MB space 
>> reserved for bootblock.
>> - using negative cache for non-zfs devices
>> 
>> limitations: 
>> - no writes. at all. never will be;)
>> - actual pool configuration is limited by disks visibility for grub, and 
>> that depends on actual system. if grub can see 4 disks, that will set the 
>> limit.
>> - browsing encryped datasets by tree levels is not supported, full path 
>> needs to be used; as writing the encrypred datasets is possible only with 
>> solaris 11 and it has its own grub implementation, I just left encryption 
>> support as is, at least for now.
>> - mount cache code is there but not enabled; enabling it did trigger 
>> artefacts with grub graphical menu, reasons yet unknown - so far all checks 
>> with libumem for memory usage and integrity have been all OK.
>> 
>> tests done: booting with different zpool configurations, single disk, 
>> mirror, raidz, multiple vdev, 512B and 4096B sector sizes, missing disks 
>> (zpool offline and physically removed), tests are performed on illumos and 
>> unknown amount of linux systems - this code is already used by debian grub2 
>> packages.
>> 
>> the embedding support adds zfs GPT partition tag to allow grub to be 
>> embedded directly to zfs partition, without the need for BIOS boot 
>> partition. If BIOS boot partition exists, it will be used. This 
>> functionality is already implemented in Illumos (with legacy grub), so, 
>> there is no reason not to support his with grub 2 as well. 
> 
> GRUB already has embedding support for ZFS; why second patch is needed?

to support install using GPT labeled whole disk devices such as /dev/sda in 
linux. without it, the bios boot partition would be needed - which is in turn, 
unnecessary in case of zfs.

> 
>> 
>> as zfs update is pretty large, i include it compressed…
>> 
> 
> Any chance to split it in series of incremental self-contained patches?

technically I guess it may be, but it would require so much time that it would 
make whole process unreasonably long that I see no practical purpose - all the 
testing required in between steps etc…  the background of this submission is 
really simple one - I have been working to build grub2 support for illumos 
based systems for about year now, and one part of this work was to get up to 
date zfs support in grub itself. since zfs on linux project has reached to the 
state they are able to use the recent zfs features, i started to receive more 
and more requests for zfs update, and to reduce burden, I did guess the most 
reasonable thing to do was to set up this submission;)

rgds,
toomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]