[Tux3] Review incoming changes

Maciej Żenczykowski zenczykowski at gmail.com
Wed Dec 17 09:43:36 PST 2008

Just another comment:
for mirrored raid, having the superblock at the end of the volume is
often desirable (it means you can also make use of the partition in
'recovery mode' without going through the raid drivers) - hence why
people often explicitely ask for the version which stores the data at
the end of the drive, furthermore I believe v0.9 is still the default.

On Wed, Dec 17, 2008 at 04:00, Daniel Phillips <phillips at phunq.net> wrote:
> On Tuesday 16 December 2008 10:03, Mike Snitzer wrote:
>> FYI, the ondisk location for the MD superblock really depends on the
>> version (of the MD superblock) that the user elects to use.
>> v0.90 puts the MD superblock at the end of the disk (v1.0 puts it at
>> the same place).
>> v1.1 is at the start of the disk, v1.2 is 4K from the start of the disk.
> Hi Mike,
> Thanks for the MD superblock executive summary.  So by 1.1 MD was
> finally doing the right thing.
> We want to do the right thing also.  I think that means choosing a
> reasonable default and providing a way to handle unreasonable
> situations, such as protecting oneself from obsolete versions of MD
> with design mistakes.  By default, we will clear the first 4K and
> write our superblock in the second 4K.  That will take care of
> everything modern, I hope.  (Except ReiserFS?)
> We might clear a bit of the volume at the top, too, though from my
> digging below it looks for the last five years, somebody would have
> to go out of their way to place a MD superblock at the top of a
> volume instead of within the first 8K.
> To handle other situations, I propose a mkfs option, something like:
>   tux3 mkfs --clear[=supers]
> There are other reasons than defending against rogue superblocks for
> fully clearing a volume at mkfs time.  (Security anyone?)  So it could
> could be a popular option.  One flavor of this would attempt to clear
> out other known superblocks.  By default, I would like to keep the
> clearing minimal, not because of the time required (though on slow
> media like certain kinds of flash it could be significant) but because
> of a natural reluctance to accomodate ancient mistakes that have little
> practical relevance today.  The NTFS issue that started this thread is
> clearly a practical issue, somebody actually hit it.  The situation
> with MD is a little murky and could use some clarifying.  We have this
> comment:
> http://lxr.linux.no/linux+v2.6.27/drivers/md/md.c#L1053
> 1053        /*
> 1054         * Calculate the position of the superblock in 512byte sectors.
> 1055         * It is always aligned to a 4K boundary and
> 1056         * depeding on minor_version, it can be:
> 1057         * 0: At least 8K, but less than 12K, from end of device
> 1058         * 1: At start of device
> 1059         * 2: 4K from start of device.
> 1060         */
> MD superblock type 1 arrived in linux 2.5.65 on 2003-03-16, and
> included the types 0, 1 and 2:
>   http://lxr.linux.no/linux-bk+v2.5.65/drivers/md/md.c#L782
> So for five years we have had more a sensible situation with MD.  I
> don't think we will take an undue risk by clearing nothing at all at
> the top of the volume, and we will provide various flavors of mkfs
> option for those who do not agree.  Is everybody satisifed?  I didn't
> think so :-)
> Regards,
> Daniel
> _______________________________________________
> Tux3 mailing list
> Tux3 at tux3.org
> http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3

Tux3 mailing list
Tux3 at tux3.org

More information about the Tux3 mailing list