Linuxファイルシステムのガイド

投稿日: 2022-10-16 2022-10-17
タグ: Filesystems

1. 概要

ファイルシステムは私たちのデータを記述します。ファイルシステムには、フォルダ、アクセス制御、および名前付きファイルがあります。それらがなければ、私たちのディスクはほんの少しのスープになります。どこに何が保存されているのか、どこから始まっているのか、どこで終わっているのか、外部情報（メタデータ）はわかりません。

ファイルシステムの一番の仕事は、データを安全に保つことです。データにすばやくアクセスし、管理しやすくする必要があります。何よりも、データが正しく、配置する場所に配置する必要があります。ストレージハードウェアの障害（ハードドライブのクラッシュ）は、非常に一般的であり、統計的にです。これは、データが私たちにとって価値がある場合は、ストレージ管理をより深く調査する必要があることを意味します。

ファイルシステムを無視してデフォルトを使用するのは簡単です。今日のLinuxでは、これはext4またはXFSファイルシステムを意味します。ただし、brtfsおよびZFSというより高度なオプションがあります。これらの「次世代」ファイルシステムにより、大量のストレージでより柔軟かつ安全に作業できます。

この記事では、デフォルトのファイルシステムから得られるもののいくつかと、次世代のファイルシステムが提供するものについて説明します。

2. デフォルト：ext4およびXFS

時間の経過とともに、これら2つのファイルシステムは非常に類似したニーズに対応するように成長しました。それらは高速で信頼性の高いジャーナリングファイルシステムです。 Ubuntuは、2009年のKarmic Koalaリリース以降、デフォルトでext4を使用しています。 2010年のRedHatEnterpriseLinux6.0もext4を使用していました。 RHEL7.0は2014年にXFSに移行しました。

ファイルシステムは、安定したシステムの基本的な部分であるため、カーネルとディストリビューションのメンテナは、変更を採用する際にゆっくりと慎重に移動します。

今日UbuntuまたはDebianをインストールすると、ストレージはext4を使用します。 Red Hat Enterprise LinuxまたはSuSEをインストールすると、XFSが取得されます。

2.1. 昨日のハイテク：ジャーナル、エクステント、および限定チェックサム

Linuxの導入以来、これら2つのファイルシステムは機能の同等性においてますます緊密になっています。 XFSはより高度なものから始まり、引き続き正常に機能します。ただし、ext4は、かつて差別化されていたXFSの多くを正常に追加できるようになりました。

Journals ：ファイルシステム「journal」は、ファイルシステムへのすべての変更の複製ログを書き込みます。ファイルシステムへの書き込みが中断された場合（停電）、システムはジャーナルを調べて「再生」し、データの損失とファイルの破損を最小限に抑えます。（以前は、ファイルシステムの正確性は fsck のような「チェッカー」ツールに依存していました。）
エクステント：従来、ファイルシステムはブロックごとにコンテンツの「マップ」を維持していました。デフォルトのブロックは通常4,096バイトであるため、ストレージが増えるにつれて、これらのマップがどれだけ大きくなったかを想像できます。代わりに、XFSとext4は、「エクステント」と呼ばれるより大きなチャンクにデータの断片をマップします。具体的には、エクステントマップは、開始ブロックアドレスとエクステントの長さ（ブロック単位）の2つの数値です。これは、大容量および大容量ファイルでうまく機能し、各ブロックのファイルメンバーシップを追跡する必要がなくなります。
チェックサム：データが破損していないことをどのようにして知ることができますか？ 1つの方法は、チェックサムを計算することです。これは、大きなデータが変化したときに変化する短い「マジックナンバー」です。以前は、発音が難しいfsckというチェックアンドリペアプログラムを実行してこれを行っていました。 XFSとext4は、メタデータとそのジャーナルファイルのチェックサムを計算するようになりました。これは便利ですが、btrfsおよびZFSのブロックごとのチェックサムよりもはるかに完全ではありません。

ext4とXFSはどちらもその機能に優れていますが、どちらも今日のより複雑なストレージの課題のいくつかには適していません。

2.2. extファイルシステム

「拡張ファイルシステム」は、Linuxで使用されている最も一般的なファイルシステムです。 1992年のextから始まり、ファイルシステムは1993年にext2に急速に移行し、2001年にext3でジャーナルを追加するようになり、2008年にext4で将来を見据えた調整が行われました。

ext4ファイルシステムは、前任者の哲学を引き継いでいます。高速で、壊れた場合は修正してください。ただし、ext3とext4は、ジャーナルや制限付きチェックサムなどのデータ安全機能を追加します。

ext4は、より大きなボリュームとファイルも可能にします（ext3の最大16テラバイトから）。 extends の採用は、メディアや一部のデータベースなどのより大きなファイルにさらに役立ちます。

しかし、ext4は多くの小さなファイルのコレクションでもうまく機能します。これは、サブディレクトリのext3の以前の上限を削除します（ext3は明らかに寛大な32,000でトップになりました）。

Linuxのデフォルトである限り、extシリーズのファイルシステムが存続しているのには理由があります。速度と「十分な」データ検証を優先するのは、十分にテストされた主力製品です。

2.3. XFS：「ビッグアイアン」の90年代

Silicon Graphics、Inc.は、1993年にIRIXUnixOS用にXFSを作成しました。 SGIは、コンピューターグラフィックス制作の限界を押し上げたことで有名です。彼らはこれを達成するために独自のカスタムハイエンドで高度に並列化されたハードウェアに依存していました。

その結果、SGIには、複数のCPUとドライブコントローラーを使用して巨大なファイルを確実にアドレス指定できるファイルシステムが必要でした。信頼性とは、ファイルの破損を防ぐためにジャーナルを保持することを意味しました。大きなファイルをアドレス指定するということは、XFSを64ビットにすることを意味していました（64ビットがクールになる前に）。また、複数のCPUがこれらの巨大なファイルを読み書きできるようにすることは、XFSの開発者が、アクセス中にiノードの周りにロックを配置するという標準的な方法を削除する必要があることを意味しました。

潜在的に数百のCPUコアによる同時アクセスを許可することの追加の複雑さを想像することができます！しかし、ソフトウェアシステムを設計することで、このきめ細かい設計は、高度に並列化されたハードウェアに報われました。 macOSやiOSがAppleハードウェアに適合するように、XFSはSGIのエコシステムに適合します。

XFSはLinuxに移植され、2001年にカーネルに入りました。現在、ほぼすべてのLinuxディストリビューションで利用可能で信頼性があります。

大容量のストレージ要件、大容量のファイル、およびマルチスレッドI / Oを備えたシステムを構築している場合は、XFSを検討する必要があります。ただし、負荷が小さくて軽い場合は、ext4の方が適している可能性があります。

私たちのシステムはメディアファイルやビッグデータを精査しますか？もしそうなら、XFSまたは次世代ファイルシステムの1つを調べる必要があります。

マイクロサービスを実行しますか？その場合は、ext4に固執することをお勧めします。

2.4. 試してみる

ついに！手を汚しましょう！さまざまなファイルシステムを体験する最も簡単な方法は、Linuxの新規インストールです。しかし、既存のシステムで実験したい場合は、それもオプションです。

ext4ファイルシステムはすでにどこにでもあります。 /sbinディレクトリを見てみましょう。

$ ls -l /sbin/mkfs.ext*
lrwxrwxrwx 1 root root 6 Feb 21 23:30 /sbin/mkfs.ext2 -> mke2fs
lrwxrwxrwx 1 root root 6 Feb 21 23:30 /sbin/mkfs.ext3 -> mke2fs
lrwxrwxrwx 1 root root 6 Feb 21 23:30 /sbin/mkfs.ext4 -> mke2fs

これらのリンクは、バイナリ mke2fs を便利に実行しますが、直接実行して、-tオプションを使用してファイルシステムタイプを指定することもできます。

まず、保持したいファイルシステムを誤って破壊していないことを再確認します。 lsblk を使用して使用可能なブロックデバイスを確認し、dfを使用してマウントされたデバイスを比較できます。

次に、mkfsプログラムをデバイスに向けるのと同じくらい簡単です。

$ sudo /sbin/mkfs.ex4 /dev/sdc

次に、マウントポイントとして機能するディレクトリを作成し、mountを実行します。再起動するたびに新しいファイルシステムをマウントする場合は、fstabに行を追加します。

XFSでこれを実行する場合は、最初にユーザーランドツールをインストールする必要があります。（ファイルシステムのサポートは、ほとんどのカーネルにすでに組み込まれています。必要なのは、それを作成して操作できるプログラムだけです。）

DebianとUbuntuでは、aptを使用してxfsprogsパッケージをインストールします。

$ sudo apt install xfsprogs

次に、matchingコマンドを実行して、ブロックデバイスをXFSで初期化します。

$ sudo /sbin/mkfs.xfs /dev/sdc

マウントしたら、実験して、ニーズにどのように適合するかを確認できます。

2.5. RAIDおよび論理ボリュームマネージャー

RAID と論理ボリュームオプションの詳細な調査は別の記事の問題ですが、それらがファイルシステムとどのように相互作用するかを理解する必要があります。

RAIDと論理ボリュームマネージャーは異なる動作をしますが、どちらも、複数の物理ディスクを1つの抽象ボリュームと見なすことができます。

ブロックデバイス上に直接ファイルシステムを作成する代わりに、ディスクをコレクションに追加し、コレクションを1つのファイルシステムを持つ1つのデバイスと見なします。

たとえば、2つのディスク（LVM2の用語では物理ボリューム）を1つの仮想ボリュームに結合する場合があります。

$ lsblk -f -e7 -o NAME,FSTYPE,FSVER,FSAVAIL,MOUNTPOINT
NAME                   FSTYPE      FSVER    FSAVAIL MOUNTPOINT
sda                                                 
├─sda1                 ext2        1.0        63.9M /boot
├─sda2                                              
└─sda5                 LVM2_member LVM2 001         
  ├─salvage--vg-root   ext4        1.0       388.7G /
  ├─salvage--vg-swap_1 swap        1                [SWAP]
  └─salvage--vg-home   ext4        1.0       274.2G /home
sdb                    LVM2_member LVM2 001         
└─salvage--vg-root     ext4        1.0       388.7G /

ここで、sda5パーティションとsdbドライブはどちらも、単一のボリュームグループ（ vgdisplay [を使用して確認）に収集された物理ドライブ（ pvdisplay を使用して確認）です。 X182X]）、ファイルシステムが存在する論理ボリュームに割り当てられます（ lvdisplay を使用して確認してください）。

ルートマウントポイント（ salvage–vg-root ）が2つの異なる物理ドライブ（sda5とsdb）のスペースをどのように使用しているかに注目してください。最新のLinuxは、 lvm を使用してこれを何年にもわたって行っており、使用可能なすべてのスペースを使用したり、ライブミラーコピーとして一部を確保したりできます。

新しい物理ディスクを追加したり、ボリュームとファイルシステムのサイズを変更したりすることもできます。柔軟であると便利です！

データをどのように分散させるかには、リスクと見返りの両方があります。 1つのディスクが故障した場合、データは失われますか？ 10個のディスクと2個のダイを使用する場合はどうでしょうか。

これらは長期的なデータストレージにとって重要な質問ですが、RAIDとLVMの「古い方法」のソリューションでは答えが大きく異なります。 ZFSとbtrfsは、この記事の後半で説明するように、これらの問題に対してより統合されたアプローチをもたらします。

3. 次世代ファイルシステム：何と理由

昔ながらの、戦闘でテストされたファイルシステムには、これらすべての優れた機能があります。なぜこれ以上何かが必要になるのでしょうか。

実際、一部のユースケースは、従来の信頼できるソリューションによって非常にうまく機能します。

しかし、新しいファイルシステムはストレージの問題を解決して統合します。 ZFSは、RAIDコントローラー、ボリュームマネージャー、およびファイルシステムを組み合わせたものです。しかし、それはさらに多くのことを行い、ファイルシステムがどのようにマウントされ共有されるかを再考します。また、btrfsは、ストレージに関する基本的な前提を作り直す必要をなくしながら、いくつかの同様の機能目標を達成します。

3.1. 新しい注目点：コピーオンライト、エラー検出、スナップショット、およびレプリケーション

btrfsとZFSはどちらも、以前のファイルシステムからの3つの特定の設計と機能の変更を強調しています。

コピーオンライト（COW）は、データをその場で上書きしないことで機能します。ファイルまたはファイルシステムが不整合な状態になることを心配する必要がなくなりました。古いファイルシステムでは、何か問題が発生したときにファイルを保存している最中（停電、ハードウェアエラーによるビットの反転、宇宙線）が発生し、そのファイルが破損する可能性があります。

代わりに、COWファイルシステムでは、メモリ内のデータの変更がディスクの新しい領域に書き込まれます。それが完了すると、ファイルを参照するものはすべて、ディスク上の新しいファイルの場所を指すように変更されます。

たとえば、ディレクトリエントリには、その中のすべてのファイルとそのブロックアドレスのリストが保持されます。新しいコピーが完了すると（前ではなく）、新しいブロックアドレスを参照するようにディレクトリエントリが変更されます。メタデータの変更は、同様のプロセスを介して機能します。

COWのもう1つの重要な要素は、ファイルが変更されない場合はコピーする必要がないことです。代わりに、「浅いコピー」はシンボリックリンクのように機能し、実際に何かが変更されたときにのみデータを複製します。

エラー検出はファイルシステムによってブロックごとに実行されるようになりました。古き良き時代には、 fsck を実行して、発生する可能性のあるデータエラーを修正する必要がありました。 ext4またはXFSを使用しても、ジャーナルが再生されるのを待つ必要があります。古いスタイルのRAIDは、他のすべてのディスクをチェックする必要があるため、再構築に長い時間がかかります。

さらに悪いことに、ドライブが大きくなるにつれて、サイレントデータ破損エラーが検出されなくなることがわかっています。 ブロックレベルのチェックサムを使用すると、ファイルシステムに依存してこれらのエラーを修正できます。

たとえば、ZFSのファイルが複数のドライブに分散していて、その個々のブロックがミラーリングされて複製されている場合があります。これらのブロックの1つが破損すると、そのチェックサムが変更されます。

ZFSは、そのチェックサムとそのミラーリングされたブロックのチェックサムを計算します。これらを、ブロックが最後に更新されたときの保存されたチェックサムと比較します。ファイルに問題がなければ、これらはすべて同一である必要があります。しかし、1つが悪い場合、それが破損していることがわかります。 ZFSは、正常なチェックサムを持つブロックを使用して、破損したブロックを自動的に「修復」できます。

ボリュームの現在の状態のスナップショットにより、ロールバックとレプリケーションが可能になります。コピーオンライトとは、データが追加または変更されたときにのみ新しいスペースを占める、影響の少ない「浅い」コピーを作成できることを理解しています。これにより、危険な変更を加える前にVMのスナップショットを作成するのと同様に、コンピューターの状態のスナップショットを作成できます。

sendおよびreceiveコマンドを使用して、スナップショットと2つのスナップショット間の差分を送信することもできます。これらのコマンドは、btrfsとZFSの両方に存在します。（クラウドレプリケーションサービスもあります！）

4. より良い/バターファイルシステム

btrfs、つまり「 B-Tree 」ファイルシステムは、ZFSの進歩の多くをより簡単な方法で（そしてライセンスの問題が少ない方法で）Linuxに持ち込もうとします。 2009年からLinuxカーネルに組み込まれていますが、現在も活発に開発されています。

大規模なデータセンターでの採用が見られますが、堅実な安定性に対するZFSの評判を享受していません。

4.1. btrfsハンズオン

btrfsを体験する最も簡単な方法の1つは、Fedora33以降を新規インストールすることです。より複雑な機能を理解しなくても、btrfsへの移行が簡単になります。 Fedoraのインストールは次のようになります。

$ lsblk -f -o NAME,FSTYPE,LABEL,MOUNTPOINT
NAME   FSTYPE LABEL                 MOUNTPOINT
sr0                                 
zram0                               [SWAP]
vda                                 
├─vda1 ext4                         /boot
└─vda2 btrfs  fedora_localhost-live /home

ext4は、ブートパーティションとしてFedoraが選択したもので存続していることがわかります。

UbuntuまたはDebianで実験したい場合は、いくつかの追加ツールが必要です。 XFSで行ったのと同じように、aptを使用してインストールします。

$ sudo apt install btrfs-progs

そこから、 mkfs.btrfs を使用して新しいボリュームを作成し、 btrfs deviceaddを使用してボリュームを拡張できます。

$ sudo mkfs.btrfs -L media -d raid1 /dev/vdb /dev/vdc
btrfs-progs v5.13 
See http://btrfs.wiki.kernel.org for more information.

Label:              media
UUID:               0ec28d06-b5a1-46f3-b628-30d04aeaaef3
Node size:          16384
Sector size:        4096
Filesystem size:    20.00GiB
Block group profiles:
  Data:             RAID1             1.00GiB
  Metadata:         RAID1           256.00MiB
  System:           RAID1             8.00MiB
SSD detected:       no
Zoned device:       no
Incompat features:  extref, skinny-metadata
Runtime features:   
Checksum:           crc32c
Number of devices:  2
Devices:
   ID        SIZE  PATH
    1    10.00GiB  /dev/vdb
    2    10.00GiB  /dev/vdc

この出力は、「セクターサイズ」など、多くの詳細といくつかの新しい用語を提供します。ここではこれらについては説明しませんが、興味深い出発点です。

ZFSとは異なり、新しいbtrfsボリュームをマウントする必要があります。 マウントコマンドまたはfstabで使用する簡単な方法は、ラベルで参照することです。

# ls /dev/disk/by-label/
fedora_localhost-live  media
# mkdir /big-media; mount /dev/disk/by-label/media /big-media

4.2. 高度な機能とリスク

つまり、btrfsは、単純なファイルシステムとして、またはRAIDコントローラーとファイルシステムとして使用できます。ただし、その開発者は、本番環境でRAID5を使用しないように警告しています。

慣れてきたら、 btrfs コマンドを使用して、次のようなより複雑な機能を調べることができます。

btrfs subvolume を使用して、ボリュームを分割し、特定の設定を適用します
btrfsサブボリュームスナップショットを使用して、バックアップまたは構成管理用のサブボリュームのライト「シャドウ」コピーを作成します
btrfs balance を使用して、使用済みブロックをすべてのストレージに再配布します
btrfsはを送信しbtrfsはを受信して、マシン間でスナップショットを送信します

Oracle Linux には、これらのコマンドの一部とより大きな問題が記載されています。

btrfsは流動的なファイルシステムであり、その使用に深刻な投資を行う場合は、FAQを頻繁に参照する必要があります。

5. ZFS：オールインワンストレージソリューション

ZFSは、2005年にOpenSolarisで開発されました。 Solaris10とオープンソースのBSDOSですぐに採用され、2014年のFreeBSD10で正式にサポートされるようになりました。

ZFSを使用すると、論理ボリュームマネージャーのようにストレージをプールできます。 RAIDのようなデータとハードウェアの冗長性を提供します（ただし、ファンキーでスマートな JBOD のようなものです）。

試してみましょう。

5.1. 実際のZFS

LinuxでのZFSの歴史は、ライセンスの問題のためにもっと複雑です。 現時点でLinuxでZFSを使用する最も簡単な方法は、Ubuntuを使用することです。zfsutils-linuxパッケージをインストールできます。または、Canonicalはデフォルトでインストーラーイメージにバンドルします。

これは「高度な機能」ですが、ZFSへのインストールとZFSからの起動の両方が可能です。ここでは、仮想テストシステムにインストールしています。

「ZFSを使用」を選択すると、それ以外はすべて透過的になります。複雑さを取り除き、便利なもの、Canonicalにたどり着く方法！

5.2. ZFSプール

仮想UbuntuZFSインストールを試してみると、次のブロックデバイスが表示されます。

$ lsblk -e7 -f -o NAME,FSTYPE,LABEL,FSUSE%,MOUNTPOINT
NAME   FSTYPE     LABEL FSUSE% MOUNTPOINT
sr0                            
vda                            
├─vda1                         
├─vda2 vfat                 3% /boot/efi
├─vda3 swap                    [SWAP]
├─vda4 zfs_member bpool        
└─vda5 zfs_member rpool

では、 bpoolとrpoolとは何ですか？ zpoolコマンドで確認できます。

$ zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
bpool  1.12G   148M  1004M        -         -     0%    12%  1.00x    ONLINE  -
rpool    22G  3.52G  18.5G        -         -     3%    16%  1.00x    ONLINE  -

うーん。 bpoolは2つのうち小さい方であることがわかります。調べてみると、Ubuntuがインストールを「ブート」プールと「ルート」プールに分割することを決定したことがわかります。これらをLVMの例のパーティション分割方法と比較すると、非ZFS Ubuntuレイアウトでは、専用のext2パーティションに / boot が保持され、 /homeと/[ X185X]（ルート）異なる論理ボリューム上。

UbuntuがZFSプールをどのように編成するかを見てみましょう。

$ zfs list
NAME                                               USED  AVAIL     REFER  MOUNTPOINT
bpool                                              147M   876M       96K  /boot
bpool/BOOT                                         147M   876M       96K  none
bpool/BOOT/ubuntu_70wzaj                           147M   876M     81.7M  /boot
rpool                                             3.52G  17.8G       96K  /
rpool/ROOT                                        3.51G  17.8G       96K  none
rpool/ROOT/ubuntu_70wzaj                          3.51G  17.8G     2.44G  /
rpool/ROOT/ubuntu_70wzaj/srv                        96K  17.8G       96K  /srv
rpool/ROOT/ubuntu_70wzaj/usr                       336K  17.8G       96K  /usr
rpool/ROOT/ubuntu_70wzaj/usr/local                 240K  17.8G      128K  /usr/local
rpool/ROOT/ubuntu_70wzaj/var                       993M  17.8G       96K  /var
rpool/ROOT/ubuntu_70wzaj/var/games                  96K  17.8G       96K  /var/games
rpool/ROOT/ubuntu_70wzaj/var/lib                   983M  17.8G      862M  /var/lib
rpool/ROOT/ubuntu_70wzaj/var/lib/AccountsService   168K  17.8G      104K  /var/lib/AccountsService
rpool/ROOT/ubuntu_70wzaj/var/lib/NetworkManager    404K  17.8G      140K  /var/lib/NetworkManager
rpool/ROOT/ubuntu_70wzaj/var/lib/apt              79.5M  17.8G     79.2M  /var/lib/apt
rpool/ROOT/ubuntu_70wzaj/var/lib/dpkg             40.2M  17.8G     31.2M  /var/lib/dpkg
rpool/ROOT/ubuntu_70wzaj/var/log                  8.41M  17.8G     3.19M  /var/log
rpool/ROOT/ubuntu_70wzaj/var/mail                   96K  17.8G       96K  /var/mail
rpool/ROOT/ubuntu_70wzaj/var/snap                  532K  17.8G      532K  /var/snap
rpool/ROOT/ubuntu_70wzaj/var/spool                 280K  17.8G      112K  /var/spool
rpool/ROOT/ubuntu_70wzaj/var/www                    96K  17.8G       96K  /var/www
rpool/USERDATA                                    4.99M  17.8G       96K  /
rpool/USERDATA/a_40qa3s                           4.73M  17.8G     2.43M  /home/a
rpool/USERDATA/root_40qa3s                         168K  17.8G      112K  /root

わお！ Canonicalは、rpoolに多くの子ファイルシステムをセットアップしました。そのため、ストレージプールのセクションを非常にきめ細かく制御できます。 rpool、にディスクまたはディスクセットを追加すると、その新しいスペースをどこでも、どこでも使用できます。（既存のプールにストレージを追加するには注意が必要な要素があるため、購入する前に調査してください。）

また、ここに表示される各マウントポイントには、独自の設定（クォータ、圧縮、およびIOチューニングの変更）を設定できます。さらに優れている点：デフォルトでは、親から設定を継承します。 zfsコマンドを使用して/var を設定し、自動圧縮を使用する場合：

$ sudo zfs set compression=lz4 rpool/ROOT/ubuntu_70wzaj/var

これで、 /varの下のすべてもlz4圧縮を使用します。

これは小規模なシステムではそれほど重要ではないかもしれませんが、サイズを拡大する必要がある場合は、ZFSがこのように機能することを嬉しく思います。

5.3. 独自のプールの作成

まず、簡単なコマンドが必要です。

その前に、ディスクを特定する必要があります。仮想マシンに2つの小さなストレージデバイスを追加しましょう。 Ubuntuのbpoolとrpoolは/dev / vda にインストールされているため、これら2つは / dev /vdbと/になります。 dev /vdc。

zpoolには多くのオプションがあります。 zpool create は、ドライブをvdev（仮想デバイス）にアセンブルし、vdevをプールにアセンブルします。

# zpool create mpool /dev/vdb /dev/vdc

または、2つのストレージデバイスで構成される単一のミラーリングされたvdevを作成できます。

# zpool create mpool mirror /dev/vdb /dev/vdc

このコマンドは、ZFSに新しいストレージプールを作成するように要求します。プールの名前は「mpool」になりますが、任意の名前を付けます。これはミラーリングされたvdevで構成され、vdevはvdbおよびvdcデバイスで構成されます。

mpool を作成したら、 zpoolstatusを使用して詳細を確認します。

# zpool status mpool
  pool: mpool
 state: ONLINE
config:

	NAME        STATE     READ WRITE CKSUM
	mpool       ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    vdb     ONLINE       0     0     0
	    vdc     ONLINE       0     0     0

errors: No known data errors

そして、それが自動的にマウントされていることに気づきました。

# df /mpool
Filesystem     1K-blocks  Used Available Use% Mounted on
mpool            9650176   128   9650048   1% /mpool

マウントポイントは簡単に変更できますが、 / etc /fstabに触れる必要はありません。 ZFSは、すべてのマウントポイントをメタデータとして格納します。

5.4. ZFSサブボリューム

media プールを整理したい場合はどうなりますか？おそらく、それぞれが異なるクォータを使用するか、プールの一部を透過的に圧縮する必要があります。

これを行うには、 zfscreateコマンドに戻ります。

# zfs create mpool/Movies
# zfs create mpool/Television
# zfs list -r mpool
NAME               USED  AVAIL     REFER  MOUNTPOINT
mpool              184K  9.20G       25K  /mpool
mpool/Movies        24K  9.20G       24K  /mpool/Movies
mpool/Television    24K  9.20G       24K  /mpool/Television

そして、「練習」プールを取り除きたい場合は、次のように簡単です。

zpool destroy mpool

探索する他のコマンドには、以下の使用が含まれます。

zpoolチェックポイントプールの現在のステータスを保存します
zpool import は、OSが既存のプールまたはチェックポイントを使用できるようにします
zpool scrub 、チェックサムを検証し、エラーを自動的に修復します
zfsスナップショットおよびzfsロールバックは、ZFSシステム全体への変更を管理します

5.5. ZFSデザイン

このフレームワークは、ZFSがストレージを処理する方法を示しています。ここで、論理ボリュームマネージャーとRAID機能を取得します。

ストレージデバイス：物理ディスクおよび/またはパーティション
仮想デバイス：抽象ストレージ、単一ディスク、ミラーリングされたコレクション、またはRAID-Zアレイ。ストレージデバイスから構築
ストレージプール： zpoollistを実行したときに表示されるzpool。これは、ファイルとディレクトリが存在する場所です。

ZFSは、ストレージプールのデータをすべてのプールのデバイスに分散します。このように、Linuxの論理ボリュームマネージャーに似ています。ミラーリングされたvdevまたはRAID-Zvdevが含まれている場合は、データの冗長性もあり、完全バックアップから復元せずにディスク障害から回復できます。

zpoolにvdevを追加する一方で、vdevを構成するデバイスを変更することは難しいことに注意することが重要です。ハードウェア構成を単純に変更して、ファイルシステムに処理させることはできません。このシナリオを非常にスムーズに処理するbtrfsとは異なり、 ZFSの変更には、より多くの計画が必要になる場合があり、場合によっては最初から始めることもあります。

6. その他のファイルシステム

Linuxは、歴史的または互換性の理由から、多くのファイルシステムをサポートしています。さらに、ネットワークを介してボリュームを共有またはアクセスしたい場合がよくあります。

6.1. ネットワーク上のどこか：NFSとSMB

NFS（ネットワークファイルシステム）はUnixで生まれましたが、SMBはWindowsとmacOSで一般的に使用されています。 Linuxマシンがこれらのファイルシステムにアクセスするときにmkfsを実行する必要はありませんが、マウント後は、ローカルファイルシステムと同じように透過的に使用できる必要があります。

NAS も表示される場合があります。これは、NFS、SMB、または別のネットワークファイルプロトコルを介してスペースを共有する専用のファイルサーバーマシンです。

一方、SANは、iSCSIやファイバーチャネルなどのプロトコルを使用して、ブロックレベルでネットワーク経由でストレージを接続します。 Linuxの観点からは、これはハードドライブのような別のブロックデバイスです。フォーマットするか、ZFSプールに追加することができます。

6.2. AmazonのElasticBlockStore（EBS）

繰り返しになりますが、このトピックはこの記事の範囲を超えていますが、クラウドプロバイダーは、ブロックレベルのデバイスとして扱うことができる長期ストレージを提供していることに注意してください。

AWS EBS は、エフェメラルクラウドインスタンスの問題を透過的に解決します。 EBSで説明した任意のファイルシステムを使用できます。

次世代のファイルシステムは、クラウドインスタンスで使用する場合はまだ一般的ではありません。たとえば、DigitalOceanは、ext4またはXFSを使用するためにブロックストレージを自動的にセットアップします。 ZFSまたはbtrfsは、自分たちでやる気がある場合に機能します。

この採用が遅い理由の1つは、ZFSのメモリに対する高いニーズにあります。より小さなインスタンスを使用してお金を節約しようとしている可能性があります。そのような環境を注意深く監視する必要があります。

6.3. さらに興味深い

ファイルシステムに関心を持ったら、調査することがどれだけあるかは驚くべきことです。

Dominic Giampaoloの著書Beファイルシステムを使用した実用的なファイルシステム設計は、1999年頃のファイルシステムアートの状態の詳細なスナップショットを提供します。
APFS 、iOSデバイスおよび最新のmacOSで使用されるファイルシステム：数百万のアクティブなデバイスのシームレスな変換は、エンジニアリングの驚異でした。
MicrosoftのNTFSでの巧妙な設計の選択。
Jim Salterのブログと次世代ファイルシステムに関するプレゼンテーションは、非常に詳細な情報でいっぱいです。

7. 結論

この記事では、Linuxで現在選択されている主なファイルシステムについて説明しました。

次世代のファイルシステムは多くのストレージの問題を解決しますが、学習曲線もあります。

ストレージのニーズが高まるにつれ、これらの新しいファイルシステムの新機能と構成はますます便利になり、必要になります。

要約すれば：

ext4は標準であり、安全な選択です。
XFSは非常に安定しており、大きなファイルや大量のマルチプロセッシングに最適です。
btrfsは柔軟で強力ですが、それでも動くターゲットのようなものです。
ZFSは十分にテストされており、非常に信頼性がありますが、より複雑です。複雑さと引き換えに、ストレージの問題を大規模に解決します。

クラウンジュエルをbtrfsまたはZFSに配置する準備ができていない場合でも、今すぐそれらのコストとメリットを調査することは理にかなっています。

getdocs

13036