From: david on
On Mon, 15 Feb 2010, H. Peter Anvin wrote:

> On 02/15/2010 04:27 PM, Neil Brown wrote:
>
> There are three options:
>
> a) either don't boot from it (separate /boot);
> b) use a bootloader which installs in the MBR and
> hopefully-unpartitioned disk areas (e.g. Grub);
> c) use a nonstandard custom MBR.
>
> Neither (b) or (c), of course, allow for chainloading from another OS
> install and thus are bad for interoperability.

I have had no problems with XFS partitions and lilo as the bootloader.
I've been doing this for a couple of years now without realizing that
there is supposed to be a problem.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: John Robinson on
On 16/02/2010 03:18, david(a)lang.hm wrote:
> On Mon, 15 Feb 2010, H. Peter Anvin wrote:
>
>> On 02/15/2010 04:27 PM, Neil Brown wrote:
>>
>> There are three options:
>>
>> a) either don't boot from it (separate /boot);
>> b) use a bootloader which installs in the MBR and
>> hopefully-unpartitioned disk areas (e.g. Grub);
>> c) use a nonstandard custom MBR.
>>
>> Neither (b) or (c), of course, allow for chainloading from another OS
>> install and thus are bad for interoperability.
>
> I have had no problems with XFS partitions and lilo as the bootloader.
> I've been doing this for a couple of years now without realizing that
> there is supposed to be a problem.

There isn't, if you use partitions. It could (would) go wrong if you
tried to put an XFS filesystem, or md RAID with a v1.1 superblock, on a
whole disc without a partition table *and* you tried to put a bootloader
on. I can't say it's ever occurred to me to do that, because I always
assumed that whatever I put in a partition used all of it, and I
couldn't expect to double-book the beginning of it and have it work.

Cheers,

John.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on
On 02/15/2010 07:18 PM, david(a)lang.hm wrote:
> On Mon, 15 Feb 2010, H. Peter Anvin wrote:
>
>> On 02/15/2010 04:27 PM, Neil Brown wrote:
>>
>> There are three options:
>>
>> a) either don't boot from it (separate /boot);
>> b) use a bootloader which installs in the MBR and
>> hopefully-unpartitioned disk areas (e.g. Grub);
>> c) use a nonstandard custom MBR.
>>
>> Neither (b) or (c), of course, allow for chainloading from another OS
>> install and thus are bad for interoperability.
>
> I have had no problems with XFS partitions and lilo as the bootloader.
> I've been doing this for a couple of years now without realizing that
> there is supposed to be a problem.
>

LILO also can be stuffed in the MBR (and then uses block-pointers from
there). There is one more option that I didn't mention, which is to put
the bootloader of a separate partition, OS/2 style. Again, breaks the
standard chainloading model.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Rudy Zijlstra on
H. Peter Anvin wrote:
> On 02/15/2010 07:18 PM, david(a)lang.hm wrote:
>> On Mon, 15 Feb 2010, H. Peter Anvin wrote:
>>
>>> On 02/15/2010 04:27 PM, Neil Brown wrote:
>>>
>>> There are three options:
>>>
>>> a) either don't boot from it (separate /boot);
>>> b) use a bootloader which installs in the MBR and
>>> hopefully-unpartitioned disk areas (e.g. Grub);
>>> c) use a nonstandard custom MBR.
>>>
>>> Neither (b) or (c), of course, allow for chainloading from another OS
>>> install and thus are bad for interoperability.
>>
>> I have had no problems with XFS partitions and lilo as the bootloader.
>> I've been doing this for a couple of years now without realizing that
>> there is supposed to be a problem.
>>
>
> LILO also can be stuffed in the MBR (and then uses block-pointers from
> there). There is one more option that I didn't mention, which is to
> put the bootloader of a separate partition, OS/2 style. Again, breaks
> the standard chainloading model.
There is another configuration that fails. Use partitioned md. I do not
think it matters whether over whole device or with a partition table.
Neither grub nor lilo will boot off from it. I've tested that exensively
with a partition on the disks. I am using PXE boot to boot 2 servers
with that configuration. That adds a dependency on the pxe boot server,
but considering the function of those servers they are moot if that pxe
server is dead anyways....

Cheers,


Rudy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Justin Piszcz on


On Tue, 16 Feb 2010, Neil Brown wrote:

> On Thu, 11 Feb 2010 18:00:23 -0500 (EST)
> Justin Piszcz <jpiszcz(a)lucidpixels.com> wrote:
>
>> Hi,
>>
>> I may be converting a host to ext4 and was curious, is 0.90 still the only
>> superblock version for mdadm/raid-1 that you can boot from without having
>> to create an initrd/etc?
>>
>> Are there any benefits to using a superblock > 0.90 for a raid-1 boot
>> volume < 2TB?
>
> The only noticeable differences that I can think of are:
> 1/ If you reboot during recovery of a spare, then 0.90 will restart the
> recovery at the start, while 1.x will restart from where it was up to.
> 2/ The /sys/class/block/mdXX/md/dev-YYY/errors counter is reset on each
> re-assembly with 0.90, but is preserved across stop/start with 1.x
> 3/ If your partition starts on a multiple of 64K from the start of the
> device and is the last partition and contains 0.90 metadata, then
> mdadm can get confused by it.
> 4/ If you move the devices to a host with a different arch and different
> byte-ordering, then extra effort will be needed to see the array for
> 0.90, but not for 1.x
>
> I suspect none of these is a big issue.
>
> It is likely that future extensions will only be supported on 1.x metadata.
> For example I hope to add support for storing a bad-block list, so that a
> read error during recovery will only be fatal for that block, not the whole
> recovery process. This is unlikely ever to be supported on 0.90. However
> it may not be possible to hot-enable it on 1.x either, depending on how much
> space has been reserved for extra metadata, so there is no guarantee that
> using 1.x now makes you future-proof.
>
> And yes, 0.90 is still the only superblock version that supports in-kernel
> autodetect, and I have no intention of adding in-kernel autodetect for any
> other version.
>
> NeilBrown
>

Hi Neil,

Thanks for the response, this is exactly what I was looking for and
probably should be put in a FAQ.

Justin.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/