zoukankan      html  css  js  c++  java
  • Superblock

    Superblock

    From Linux Raid Wiki
     
    Jump to: navigation, search

    This page is obsolete; see RAID superblock formats

    Linux raid reserves a bit of space (called a superblock) on each component device. This space holds metadata about the RAID device and allows correct assembly of the array.

    There are several versions of superblocks but they can be split into 3 groups:

    • ancient (pre-0.9)
    • 0.9
    • 1.0 to 1.2

    The on-disk superblock formats info can be found here: RAID_superblock_formats

    The ancient superblocks are out of scope for this wiki and aren't used by mdadm and md.

    1.x superblocks

    1.x superblocks are new(ish)

    The version numbers simply indicate where the superblock is stored on the individual component devices.

    Version 1.0 is stored near the end of the device (at least 8K, and less than 12K, from the end). This is useful, especially with RAID-0 and RAID-10 devices, because the RAID filesystem and non-RAID filesystem starts in exactly the same place, so if you can't get RAID up you can often mount the thing directly in readonly mode and get the data off. But it has the tiny risk that writing off the end of the filesystem (when it's mounted without going through md like that) will wreck your array.

    Version 1.1 is stored at the start of the device. This eliminates the overwriting thing but stops you from directly mounting without going through md.

    Version 1.2 is like version 1.1 but stores the superblock 4K from the device start. This is particularly useful if you make a RAID array on a whole device, because this misses partition tables, master boot records, and the like.

    In practice they're nearly identical, sharing nearly all of their code:

    Do note that the in-kernel autodetect (based on partition types FD) only works for version 0.90 superblocks.

    As a workaround, distributions, Ubuntu and Fedora at least, circa early 2009, include init scripts that run any arrays that aren't started by auto-detect, which can include arrays using the newer 1.x superblocks.

    Using Fedora 9 as the example, the initscript file that does this is named /etc/rc.d/rc.sysinit. The command used is:

       # Start any MD RAID arrays that haven't been started yet
       [ -f /etc/mdadm.conf -a -x /sbin/mdadm ] && /sbin/mdadm -As --auto=yes --run
    

    The kernel automounter can't mount any of the version 1.x superblocks, and LILO can't boot off them.

    Version 1 superblocks allow for an arbitrarily large internal bitmap. It does this by explicitly given the data-start and data-size. So e.g. a 1.1 superblock could make

       data-start==1Gig
       data-size == devicesize minus 1Gig
    

    and put the bitmap after the superblock (which is at the start) and use nearly one Gig for the bitmap.

    However mdadm isn't quite so accommodating. It should:

    • when creating an array without a bitmap, leave a reasonable amount of space for one to be added in the future (32-64k).
    • when dynamically adding a bitmap, see how much space is available and use up to that much
    • when creating an array with a bitmap, honour any --bitmap-chunk-size or default and reserve an appropriate amount of space.

    I think it might do the first. I think it doesn't do the second two. Maybe in 2.6 .or 2.7

  • 相关阅读:
    随笔 Frida
    [转]某种传染病第一天只有一个患者,前五天为潜伏期,不发作也不会传染人 第6天开始发作,从发作到治愈需要5天时间,期间每天传染3个人 求第N天共有多少患者 Frida
    sql 将具有相同ID的多条记录组合成一条记录 Frida
    【转】小谈C#.NET下的爬虫(蜘蛛)技术 Frida
    ECMAScript基础1 Frida
    显示隐藏层 jquery Frida
    SQL语句备份和还原数据库
    Hello!Blog~
    23个MySQL常用查询语句
    SQL Server 2008压缩数据库日志文件
  • 原文地址:https://www.cnblogs.com/2ne1/p/5972086.html
Copyright © 2011-2022 走看看