web-dev-qa-db-ja.com

Linux上のZFSは、複数のデバイスにまたがるブートパーティションのスパンをサポートしていますか?

Linux上のZFSをルートファイルシステム自体に使用でき、興味深い wiki記事 が利用可能かどうかというトピックについて読んでいます。しかし、 例のパーティションレイアウト は私にはわかりません。

# sgdisk     -n1:0:0      -t1:BF01 /dev/disk/by-id/scsi-SATA_disk1
Run this if you need legacy (BIOS) booting:
# sgdisk -a1 -n2:34:2047  -t2:EF02 /dev/disk/by-id/scsi-SATA_disk1
Run this for UEFI booting (for use now or in the future):
# sgdisk     -n3:1M:+512M -t3:EF00 /dev/disk/by-id/scsi-SATA_disk1
Run this in all cases:
# sgdisk     -n9:-8M:0    -t9:BF07 /dev/disk/by-id/scsi-SATA_disk1

この例で私が理解していないのは、最初のパーティションです。 sgdisk のマニュアルページを読むと、最初のパーティションのサイズが1ブロックしかないのか、それとも本質的にデバイス全体をカバーしているのかがわかりません。後者の場合、他のすべての作成されたパーティションが最初のパーティション内に作成されることを意味しますか?私が不思議に思うのは、manページの次の文です。

開始値または終了値0は、デフォルト値を指定します。これは、開始セクターで使用可能な最大のブロックの開始であり、終了セクターで同じブロックの終了です。

「同じブロック」は、物理デバイスの1つのブロックのように聞こえます。したがって、たとえば、 512バイトまたは4kバイトのデータ?それとも、最終的に複数の論理/物理ブロックにまたがる、連続した量のストレージを意味しますか?

ウィキには次の文があるので、これを理解することが重要です。

ルートプールは単一のディスクである必要はありません。ミラーまたはraidzトポロジを持つことができます。その場合は、プールの一部となるすべてのディスクに対してパーティショニングコマンドを繰り返します。次に、zpool create ... rpool mirror/dev/disk/by-id/scsi-SATA_disk1-part1/dev/disk/by-id/scsi-SATA_disk2-part1を使用してプールを作成します(またはミラーをraidz、raidz2、またはraidz3を使用して、追加のディスクのパーティションを一覧表示します)。

ご覧のとおり、最初のパーティションのみがプールに配置され、上記で作成された他のパーティションはまったく言及されていません。私が理解していないのは、他のパーティションがpart1の一部であり、したがってプールでも暗黙的に使用可能であるか、プールでまったく使用されていないかです。たとえば、GRUBは他のパーティションの1つにインストールされ、この場合はZFSプールへの参照はありません。

# mkdosfs -F 32 -n EFI /dev/disk/by-id/scsi-SATA_disk1-part3
[...]
# echo PARTUUID=$(blkid -s PARTUUID -o value \
      /dev/disk/by-id/scsi-SATA_disk1-part3) \
      /boot/efi vfat nofail,x-systemd.device-timeout=1 0 1 >> /etc/fstab

part3はZFSプールの一部ではないため、個別に使用されているように私にはわかります。しかし、それはpart1のサイズにどのように適合しますか? 1つのブロックのみのパーティションはあまり意味がないようですが、part3part1に含まれている場合、それはZFSプールの一部であるが、それなしでも対処されることを意味しますか?

上記の例のように、複数のデバイスとパーティションを使用するセットアップで、ブートパーティションに冗長性がどのように提供されるかを理解する必要があります。 mdadmと比較すると、全体的な目標はRAID10セットアップであり、常に2つのデバイスがミラーリングされ、それらのデバイスのパーティションがすべてのミラーにストライプ化されます。最終的に、6つのディスクを使用すると、ブートパーティションとルートプールのストレージの3倍になります。 ZFSは一般的にそれを行うことができますが、プールの一部が何であるか、冗長性がブートパーティションもカバーしているかどうかはわかりません。

私の現在の感覚では、そうではなく、ブートパーティションを冗長にするためにmdadmが必要になるでしょう。上記のGRUBの例は、ZFSによって作成された論理ミラーではなく、物理デバイスである特定のディスクとパーティションにアクセスするためです。さらに、そのパーティションはZFSではなくFAT32でフォーマットされています。これはそうではありません。 ZFSがこれらのパーティションのいずれかをまったく気にしていないように読んでください。

それで、結局、ZFSはすべてのブートパーティション、ルートなど、本当にすべてを含むmdadmで可能なものに匹敵するRAID10セットアップをサポートしますか?

2

各ディスク(とにかく少なくとも2つ)には、ハードウェア障害が発生した場合に冗長性を提供するために、ZFSプールのnot部分であるブートパーティションが必要です。

上記の手順では、将来の変更に対する一種の予防策としてEFIブートパーティションを作成しています(EFIブートパーティションは、基本的に、ドライバーをチェーンロードするFATの小さなFATファットファイルシステムです)。

いずれにせよ、これらの最初の3つのパーティションはいずれもzpoolに属しません。最後の(最大の)パーティションだけです。

FreeBSDのルート上のZFSのこのHOWTO それをより詳細に説明します。 (ただし、コマンドが異なると、混乱が生じる可能性があります...)

次のことを考慮してください。

  • ファームウェア(BIOS、EFIなど)は何もを認識していませんが、ブートを見つける方法を知っています
  • JBOD(Just a Bunch Of Disks)以外に何もありません

ファームウェアがZFSを認識していないため、ZFSから直接起動することはできません。したがって、ファームウェアを起動できる非ZFSパーティションが必要です。これは、ZFS冗長性によって保護されないため、多くの場所にコピーを作成するのが理にかなっています。

2
quadruplebucky