linux-kernel - Re: Linux mdadm superblock question.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100216115036.0f6b7bb6@notabene.brown>
Date:	Tue, 16 Feb 2010 11:50:36 +1100
From:	Neil Brown <neilb@...e.de>
To:	Justin Piszcz <jpiszcz@...idpixels.com>
Cc:	linux-raid@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Linux mdadm superblock question.

On Thu, 11 Feb 2010 18:00:23 -0500 (EST)
Justin Piszcz <jpiszcz@...idpixels.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/