Idea: Use extended blocklist format to support installing to raid device.

Idea: Use extended blocklist format to support installing to raid device.

[Bean]

Hi,

Currently, the blocklist format can only support traditional disk. I'm
thinking about a new format that can be used in raid as well.

The new format is like this:

checksum_0 blocklist_0 checksum_1 blocklist_1 ...

The checksum is the checksum of sectors in the blocklist that follows.
For example:

c1 10+20,40+10 c2 10+50

This means 10-30,40-50 sectors from one disk, then 10-60 sectors from
another disk. The checksum is used to find the correct disk.

For traditional disk, we can also use this format, for example:

c1 10+20,40+10

This can support install to different disk than the one core.img is
in, as it will scan all disks for the correct checksum at runtime.

-- 
Bean

Re: Idea: Use extended blocklist format to support installing to raid device.

[Robert Millan]

On Tue, Aug 12, 2008 at 09:38:52AM +0800, Bean wrote:
> Hi,
> 
> Currently, the blocklist format can only support traditional disk. I'm
> thinking about a new format that can be used in raid as well.
> 
> The new format is like this:
> 
> checksum_0 blocklist_0 checksum_1 blocklist_1 ...
> 
> The checksum is the checksum of sectors in the blocklist that follows.
> For example:
> 
> c1 10+20,40+10 c2 10+50
> 
> This means 10-30,40-50 sectors from one disk, then 10-60 sectors from
> another disk. The checksum is used to find the correct disk.
> 
> For traditional disk, we can also use this format, for example:
> 
> c1 10+20,40+10
> 
> This can support install to different disk than the one core.img is
> in, as it will scan all disks for the correct checksum at runtime.

IMHO, I think we should try to get rid of blocklists, or avoid reliing on
them as much as possible.  Specially now that we have a good compression
ratio for msdos partmaps, and plenty of space on gpt ones.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Idea: Use extended blocklist format to support installing to raid device.

[Bean]

On Tue, Aug 12, 2008 at 4:57 PM, Robert Millan <rmh@aybabtu.com> wrote:
> On Tue, Aug 12, 2008 at 09:38:52AM +0800, Bean wrote:
>> Hi,
>>
>> Currently, the blocklist format can only support traditional disk. I'm
>> thinking about a new format that can be used in raid as well.
>>
>> The new format is like this:
>>
>> checksum_0 blocklist_0 checksum_1 blocklist_1 ...
>>
>> The checksum is the checksum of sectors in the blocklist that follows.
>> For example:
>>
>> c1 10+20,40+10 c2 10+50
>>
>> This means 10-30,40-50 sectors from one disk, then 10-60 sectors from
>> another disk. The checksum is used to find the correct disk.
>>
>> For traditional disk, we can also use this format, for example:
>>
>> c1 10+20,40+10
>>
>> This can support install to different disk than the one core.img is
>> in, as it will scan all disks for the correct checksum at runtime.
>
> IMHO, I think we should try to get rid of blocklists, or avoid reliing on
> them as much as possible.  Specially now that we have a good compression
> ratio for msdos partmaps, and plenty of space on gpt ones.

Hi,

Right, but we can't get rid of it totally. For example, if they don't
reserve enough space at the beginning of disk, there is no way to
install grub2 without blocklist. And, some people may want to install
to partition instead of mbr. blocklist is useful in small media as
well, like floppy, which don't the luxury of mbr.

-- 
Bean

Re: Idea: Use extended blocklist format to support installing to raid device.

[Robert Millan]

On Tue, Aug 12, 2008 at 05:20:54PM +0800, Bean wrote:
> 
> Hi,
> 
> Right, but we can't get rid of it totally. For example, if they don't
> reserve enough space at the beginning of disk, there is no way to
> install grub2 without blocklist. And, some people may want to install
> to partition instead of mbr. blocklist is useful in small media as
> well, like floppy, which don't the luxury of mbr.

My point is that users shouldn't provide this kind of insane setups and
expect GRUB to work well in them.  Instead of jumping through hoops in order
to support them no matter what, I find it perfectly reasonable that we refuse
to do it.

To me, this sounds like a slippery slope.  Users come requesting support for
all sort of weird setups all the time (I remember a recent thread from someone
who wanted to boot right away from LVM without partition table).  GRUB is
free software, so everyone can adjust it to their needs, but when we implement
the code to support one of these setups, we're basically promising to support
it in the future, deal with user problems and bug fixes.  This shouldn't be
treated lightly IMHO.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Idea: Use extended blocklist format to support installing to raid device.

[Marco Gerards]

Robert Millan <rmh@aybabtu.com> writes:

> On Tue, Aug 12, 2008 at 05:20:54PM +0800, Bean wrote:
>> 
>> Hi,
>> 
>> Right, but we can't get rid of it totally. For example, if they don't
>> reserve enough space at the beginning of disk, there is no way to
>> install grub2 without blocklist. And, some people may want to install
>> to partition instead of mbr. blocklist is useful in small media as
>> well, like floppy, which don't the luxury of mbr.
>
> My point is that users shouldn't provide this kind of insane setups and
> expect GRUB to work well in them.  Instead of jumping through hoops in order
> to support them no matter what, I find it perfectly reasonable that we refuse
> to do it.
>
> To me, this sounds like a slippery slope.  Users come requesting support for
> all sort of weird setups all the time (I remember a recent thread from someone
> who wanted to boot right away from LVM without partition table).  GRUB is
> free software, so everyone can adjust it to their needs, but when we implement
> the code to support one of these setups, we're basically promising to support
> it in the future, deal with user problems and bug fixes.  This shouldn't be
> treated lightly IMHO.

I personally have no problems with saying no from time to time :-)

--
Marco