1 Linuxファイルシステムの概要 #
SUSE Linux Enterprise Serverにはいくつかの異なるファイルシステム(Btrfs、Ext4、Ext3、Ext2、XFSなど)が付属しており、そのいずれかを選択することができます。各ファイルシステムには、それぞれ独自の利点と欠点があります。SUSE Linux Enterprise Serverにおける主要ファイルシステムの機能の対照比較については、https://www.suse.com/releasenotes/x86_64/SUSE-SLES/15-SP3/#file-system-comparison(「Comparison of supported file systems (サポートされるファイルシステムの比較)」)を参照してください。この章では、それらのファイルシステムの機能および利点の概要を説明します。
SUSE Linux Enterprise 12では、オペレーティングシステム用のデフォルトファイルシステムはBtrfsであり、他はすべてXFSがデフォルトです。また、Extファイルシステムファミリ、およびOCFS2も引き続きサポートします。デフォルトでは、Btrfsファイルシステムは複数のサブボリュームと共に設定されます。ルートファイルシステムでは、Snapperインフラストラクチャを使用して、スナップショットが自動的に有効になります。Snapperの詳細については、第10章 「Snapperを使用したシステムの回復とスナップショット管理」を参照してください。
プロ級のハイパフォーマンスのセットアップには、可用性の高いストレージシステムが必要なことがあります。ハイパフォーマンスのクラスタリングシナリオの要件を満たすため、SUSE Linux Enterprise Serverでは、High Availability ExtensionアドオンにOCFS2 (Oracle Cluster File System 2)とDRBD (Distributed Replicated Block Device)を組み込んでいます。これらの高度なストレージシステムは、本書では扱いません。詳細については、 Administration Guide for the SUSE Linux Enterprise High Availability Extensionを参照してください。
ただし、すべてのアプリケーションに最適なファイルシステムは存在しません。各ファイルシステムには特定の利点と欠点があり、それらを考慮する必要があります。最も高度なファイルシステムを選択する場合でも、適切なバックアップ戦略が必要です。
本項で使用されるデータの完全性およびデータの一貫性という用語は、ユーザスペースデータ(ユーザが使用するアプリケーションによりファイルに書き込まれるデータ)の一貫性を指す言葉ではありません。ユーザスペースのデータが一貫しているかどうかは、アプリケーション自体が管理する必要があります。
本項で特に指定のない限り、パーティションおよびファイルシステムの設定または変更に必要なすべての手順は、YaSTパーティショナを使用して実行できます(そうすることをお勧めします)。詳細については、「第10章 「」を参照してください。 」
1.1 用語集 #
- metadata
ファイルシステムが内包するデータ構造です。これにより、すべてのオンディスクデータが正しく構成され、アクセス可能になります。です。ほとんどすべてのファイルシステムに独自のメタデータ構造があり、それが各ファイルシステムに異なるパフォーマンス特性が存在する理由の1つになっています。メタデータが破損しないよう維持するのは、非常に重要なことです。もし破損した場合、ファイルシステム内にあるすべてのデータがアクセス不能になる可能性があるからです。
- inode
サイズ、リンク数、ファイルの内容を実際に格納しているディスクブロックへのポインタ、作成日時、変更日時、アクセス日時など、ファイルに関する各種の情報を含むファイルシステムのデータ構造。
- ジャーナル(journal)
ファイルシステムのジャーナルは、ファイルシステムがそのメタデータ内で行う変更を特定のログに記録するオンディスク構造です。ジャーナル機能は、システム起動時にファイルシステム全体をチェックする長時間の検索プロセスが不要なため、ファイルシステムの回復時間を大幅に短縮します。ただし、それはジャーナルが再現できる場合に限定されます。
1.2 Btrfs #
Btrfsは、Chris Masonが開発したCOW(コピーオンライト)ファイルシステムです。このシステムは、Ohad Rodehが開発したCOWフレンドリなBツリーに基づいています。Btrfsは、ロギングスタイルのファイルシステムです。このシステムでは、ブロックの変更をジャーナリングする代わりに、それらの変更を新しい場所に書き込んで、リンクインします。新しい変更は、最後の書き込みまで確定されません。
1.2.1 主な特長 #
Btrfsは、次のような耐障害性、修復、容易な管理機能を提供します。
書き込み可能なスナップショット。更新適用後に必要に応じてシステムを容易にロールバックしたり、ファイルをバックアップできます。
サブボリュームのサポート: BtrFSでは、割り当てられたスペースのプールにデフォルトのサブボリュームが作成されます。BtrFSでは、同じスペースプール内で個々のファイルシステムとして機能する追加サブボリュームを作成できます。サブボリュームの数は、プールに割り当てられたスペースによってのみ制限されます。
scrub
を使用したオンラインでのチェックと修復の機能が、Btrfsのコマンドラインツールの一部として利用できます。ツリー構造が正しいことを前提として、データとメタデータの完全性を検証します。マウントしたファイルシステム上で、scrubを定期的に実行することができます。これは、通常の操作中にバックグラウンドプロセスとして実行されます。メタデータとユーザデータ用のさまざまなRAIDレベル。
メタデータとユーザデータ用のさまざまなチェックサム。エラー検出が向上します。
Linux LVM (Logical Volume Manager)ストレージオブジェクトとの統合。
SUSE Linux Enterprise Server上でのYaSTパーティショナおよびAutoYaSTとの統合。その際、MD (複数デバイス)およびDM (デバイスマッパー)の各ストレージ設定ではBtrfsファイルシステムの作成も行われます。
既存のExt2、Ext3、およびExt4ファイルシステムからの、オフラインのマイグレーション。
/boot
のブートローダサポート。Btrfsパーティションからの起動を可能にします。マルチボリュームBtrfsは、SUSE Linux Enterprise Server 15 SP5では、RAID0、RAID1、およびRAID10プロファイルでサポートされます。それより高いレベルのRAIDは現時点サポートされませんが、将来のサービスパックでサポートされる可能性があります。
Btrfsのコマンドを使用して、透過圧縮を設定します。
1.2.2 SUSE Linux Enterprise Server上のルートファイルシステム設定 #
SUSE Linux Enterprise Serverのルートパーティションは、デフォルトでBtrfsとスナップショットを使用して設定されます。スナップショットを使用すると、更新適用後に必要に応じてシステムを容易にロールバックしたり、ファイルをバックアップしたりできます。スナップショットは、第10章 「Snapperを使用したシステムの回復とスナップショット管理」で説明するSUSE Snapperインフラストラクチャを使用して簡単に管理できます。SUSEのSnapperプロジェクトの一般情報については、OpenSUSE.orgにあるSnapper Portal wiki (http://snapper.io)を参照してください。
スナップショットを使用してシステムをロールバックする場合、ユーザのホームディレクトリ、WebサーバとFTPサーバのコンテンツ、ログファイルなどのデータがロールバック中に失われたり、上書きされたりしないようにする必要があります。それには、ルートファイルシステムでBtrfsサブボリュームを使用します。サブボリュームは、スナップショットから除外できます。インストール時にYaSTによって提示されるSUSE Linux Enterprise Serverのルートファイルシステムのデフォルト設定には、次のサブボリュームが含まれます。これらがスナップショットから除外される理由を次に示します。
/boot/grub2/i386-pc
、/boot/grub2/x86_64-efi
、/boot/grub2/powerpc-ieee1275
、/boot/grub2/s390x-emu
ブートローダ設定のロールバックはサポートされていません。これらのディレクトリは、アーキテクチャ固有です。最初の2つのディレクトリはAMD64/Intel 64マシン上に存在し、その後の2つのディレクトリはそれぞれIBM POWERとIBM Z上に存在します。
/home
/home
が独立したパーティションに存在していない場合、ロールバック時のデータ損失を避けるために除外されます。/opt
サードパーティ製品は通常、
/opt
にインストールされます。ロールバック時にこれらのアプリケーションがアンインストールされるのを避けるために除外されます。/srv
WebおよびFTPサーバ用のデータが含まれています。ロールバック時にデータが失われるのを避けるために除外されます。
/tmp
スナップショットから除外される一時ファイルとキャッシュを含むすべてのディレクトリ。
/usr/local
このディレクトリは、ソフトウェアの手動インストール時に使用します。ロールバック時にこれらのインストール済みソフトウェアがアンインストールされるのを避けるために除外されます。
/var
このディレクトリには、ログ、一時キャッシュ、
/var/opt
のサードパーティ製品など、多くのバリアブルファイルが含まれており、仮想マシンのイメージとデータベースのデフォルトの場所です。したがって、このサブボリュームはスナップショットからすべてのこのバリアブルデータを除外するように作成され、コピーオンライトが無効になっています。
SUSEがロールバックをサポートするのは、事前設定されているサブボリュームがまったく削除されていない場合のみです。ただし、YaSTパーティショナを使用して、サブボリュームを追加することはできます。
1.2.2.1 圧縮されたBtrfsファイルシステムのマウント #
Btrfsファイルシステムは透過的な圧縮をサポートしています。有効にすると、Btrfsは書き込み時にファイルデータを圧縮し、読み込み時にファイルデータを解凍します。
compress
またはcompress-force
マウントオプションを使用し、圧縮アルゴリズム(zstd
、lzo
、またはzlib
)を選択します(zlibがデフォルト値です)。zlib圧縮は、より圧縮率が高く、一方lzo圧縮はより高速でCPU負荷が低くなります。zstdアルゴリズムは、lzoに近いパフォーマンスと、zlibと類似の圧縮率を備えた最新の妥協案を提供します。
例:
#
mount -o compress=zstd /dev/sdx /mnt
ファイルを作成し、そのファイルに書き込む場合で、圧縮された結果のサイズが未圧縮サイズよりも大きいか等しい場合、Btrfsはこのファイルに以後も書き込みができるように圧縮をスキップします。この動作が必要ない場合、compress-force
オプションを使用します。最初の圧縮できないデータを含むファイルには有効です。
圧縮は、新規ファイルのみに効果があることに注意してください。圧縮なしで書き込まれたファイルは、ファイルシステムがcompress
オプションまたはcompress-force
オプションを使用してマウントされたときに圧縮されません。また、nodatacow
属性を持つファイルのエクステントは圧縮されません。
#
chattr
+C FILE#
mount
-o nodatacow /dev/sdx /mnt
暗号化は、圧縮処理とは関係のない独立した処理です。このパーティションにデータを書き込んだら、詳細を印刷してください。
#
btrfs filesystem show /mnt
btrfs filesystem show /mnt
Label: 'Test-Btrfs' uuid: 62f0c378-e93e-4aa1-9532-93c6b780749d
Total devices 1 FS bytes used 3.22MiB
devid 1 size 2.00GiB used 240.62MiB path /dev/sdb1
永続的に設定したい場合、compress
オプションまたはcompress-force
オプションを/etc/fstab
設定ファイルに追加します。例:
UUID=1a2b3c4d /home btrfs subvol=@/home,compress 0 0
1.2.2.2 サブボリュームのマウント #
SUSE Linux Enterprise Server上のスナップショットからシステムをロールバックするには、まずスナップショットからブートします。これにより、ロールバックを実行する前に、スナップショットを実行しながらチェックできます。スナップショットからブートできるようにするには、サブボリュームをマウントします(通常は不要な操作です)。
1.2.2項 「SUSE Linux Enterprise Server上のルートファイルシステム設定」の一覧に示されているサブボリューム以外に、@
という名前のボリュームが存在します。これは、ルートパーティション(/
)としてマウントされるデフォルトサブボリュームです。それ以外のサブボリュームは、このボリュームにマウントされます。
スナップショットからブートすると、@
サブボリュームではなく、スナップショットが使用されます。スナップショットに含まれるファイルシステムの部分は、/
として読み込み専用でマウントされます。それ以外のサブボリュームは、スナップショットに書き込み可能でマウントされます。この状態は、デフォルトでは一時的なものです。次回の再起動により、前の設定が復元されます。これを永久的なものにするには、snapper
rollback
コマンドを実行します。これにより、今回のブートに使用したスナップショットが新しいデフォルトのサブボリュームになり、再起動後はこのサブボリュームが使用されます。
1.2.2.3 空き領域の確認 #
通常、ファイルシステムの使用量はdf
コマンドで確認します。Btrfsファイルシステムでは、df
の出力は誤解を招く可能性があります。生データが割り当てる領域とは別に、Btrfsファイルシステムもメタデータ用の領域を割り当てて使用するからです。
その結果、まだ大量の領域を使用できるように見えても、Btrfsファイルシステムによって領域不足がレポートされることがあります。その場合、メタデータ用に割り当てられた領域はすべて使用されています。Btrfsファイルシステム上の使用済みの領域と使用可能な領域を確認するには、次のコマンドを使用します。
btrfs filesystem show
>
sudo
btrfs filesystem show / Label: 'ROOT' uuid: 52011c5e-5711-42d8-8c50-718a005ec4b3 Total devices 1 FS bytes used 10.02GiB devid 1 size 20.02GiB used 13.78GiB path /dev/sda3ファイルシステムの合計サイズとその使用量を表示します。最後の行のこれら2つの値が一致する場合、ファイルシステム上の領域はすべて割り当て済みです。
btrfs filesystem df
>
sudo
btrfs filesystem df / Data, single: total=13.00GiB, used=9.61GiB System, single: total=32.00MiB, used=16.00KiB Metadata, single: total=768.00MiB, used=421.36MiB GlobalReserve, single: total=144.00MiB, used=0.00Bファイルシステムの割り当て済みの領域(
total
)および使用済みの領域の値を表示します。メタデータのtotal
およびused
の値がほぼ等しい場合、メタデータ用の領域はすべて割り当て済みです。btrfs filesystem usage
>
sudo
btrfs filesystem usage / Overall: Device size: 20.02GiB Device allocated: 13.78GiB Device unallocated: 6.24GiB Device missing: 0.00B Used: 10.02GiB Free (estimated): 9.63GiB (min: 9.63GiB) Data ratio: 1.00 Metadata ratio: 1.00 Global reserve: 144.00MiB (used: 0.00B) Data Metadata System Id Path single single single Unallocated -- --------- -------- --------- -------- ----------- 1 /dev/sda3 13.00GiB 768.00MiB 32.00MiB 6.24GiB -- --------- -------- --------- -------- ----------- Total 13.00GiB 768.00MiB 32.00MiB 6.24GiB Used 9.61GiB 421.36MiB 16.00KiB前の2つのコマンドを組み合わせたのと同様のデータを表示します。
詳細については、man 8 btrfs-filesystem
およびhttps://btrfs.wiki.kernel.org/index.php/FAQを参照してください。
1.2.3 ReiserFSおよびExtの各ファイルシステムからBtrfsへのマイグレーション #
btrfs-convert
ツールを使用して、既存のReiserFSまたはExt (Ext2、Ext3、またはExt4)からBtrfsファイルシステムにデータボリュームをマイグレートすることができます。これにより、アンマウントされた(オフライン)ファイルシステムのインプレース変換を実行できます。これにはbtrfs-convert
ツールとともにブート可能なインストールメディアが必要な場合があります。このツールは元のファイルシステムの空き領域内にBtrfsファイルシステムを構築し、それに含まれているデータに直接リンクします。メタデータを作成するにはデバイスに十分な空き領域が必要です。さもないと変換に失敗します。元のファイルシステムはそのままとなり、Btrfsファイルシステムによって空き領域が占有されることはありません。必要なスペースの量はファイルシステムのコンテンツによって決まりますが、そこに含まれるファイルシステムオブジェクト(ファイル、ディレクトリ、拡張属性)の数によって左右される場合があります。データは直接参照されるため、ファイルシステム上のデータ量は変換に必要なスペースに影響を与えません。ただし、テールパッキングを使用するファイルや2KiBを超えるサイズのファイルは除きます。
ルートファイルシステムをBtrfsに変換する操作はサポートも推奨もされません。さまざまなステップをそれぞれのセットアップに合わせる必要があるため、このような変換の自動化は不可能です。このプロセスには、適切なロールバックを実行するために複雑な設定を行う必要があり、/boot
がルートファイルシステム上にある必要があり、システムに専用のサブボリュームが存在する必要があるなどの要件があります。そのため、既存のファイルシステムを保持するか、新たにシステム全体を再インストールしてください。
元のファイルシステムをBtrfsファイルシステムに変換するには、次のコマンドを実行します。
#
btrfs-convert /path/to/device
/etc/fstab
変換後は、/etc/fstab
に記載されている元のファイルシステムへのすべての参照で、デバイスにBtrfsファイルシステムがあることが示されるように調整されていることを確認する必要があります。
変換時には、Btrfsファイルシステムのコンテンツにソースファイルシステムのコンテンツが反映されます。ソースファイルシステムは、fs_root/reiserfs_saved/image
で作成された関連する読み込み専用イメージを削除するまで保持されます。イメージファイルの実態は、変換前におけるReiserFSファイルシステムの「スナップショット」であり、Btrfsファイルシステムが変更されても変わりません。イメージファイルを削除するには、reiserfs_saved
サブボリュームを削除します。
#
btrfs subvolume delete fs_root/reiserfs_saved
ファイルシステムを元に戻すには、次のコマンドを使用します。
#
btrfs-convert -r /path/to/device
Btrfsファイルシステムとしてマウントされているファイルシステムへの変更はすべて失われます。マウント中には負荷分散操作を実行しないでください。さもないと、ファイルシステムが正しく復元されなくなります。
1.2.4 Btrfsの管理 #
Btrfsは、YaSTパーティショナおよびAutoYaST内に統合されています。これはインストール時に利用可能で、ルートファイルシステム用のソリューションを設定することができます。インストール後に、YaSTパーティショナを使用して、Btrfsのボリュームの参照と管理を行うことができます。
Btrfsの管理ツールは、btrfsprogs
パッケージ内に用意されています。Btrfsコマンドの使用については、man 8 btrfs
、man 8
btrfsck
、およびman 8 mkfs.btrfs
の各コマンドを参照してください。Btrfsの機能については、Btrfs wiki (http://btrfs.wiki.kernel.org)を参照してください。
1.2.5 サブボリュームに対するBtrfsクォータのサポート #
Btrfsルートファイルシステムのサブボリューム(/var/log
、/var/crash
、または/var/cache
など)が、通常の操作時に利用可能なディスクスペースのすべてを使用でき、システムに不具合が発生します。この状況を回避するため、SUSE Linux Enterprise ServerではBtrfsサブボリュームに対するクォータのサポートを提供するようになりました。YaSTの提案からルートファイルシステムを設定すると、サブボリュームのクォータを有効にして設定する準備が整います。
1.2.5.1 YaSTを使用したBtrfsクォータの設定 #
YaSTを使用してルートファイルシステムのサブボリュームにクォータを設定するには、次の手順に従います。
YaSTを起動し、
› を選択して、 で警告を確認します。左側のペインで、
をクリックします。メインウィンドウで、サブボリュームクォータを有効にするデバイスを選択して、下部にある
をクリックします。- 図 1.1: Btrfsクオータの有効化 #
既存のサブボリュームのリストから、クォータでサイズを制限するサブボリュームをクリックし、下部にある
をクリックします。- 図 1.2: サブボリュームのクォータの設定 #
サブボリューム名の横に新しいサイズ制限が表示されます。
図 1.3: デバイスのサブボリュームのリスト #
1.2.5.2 コマンドラインでのBtrfsクォータの設定 #
コマンドラインでルートファイルシステムのサブボリュームにクォータを設定するには、次の手順に従います。
クォータサポートを有効にします。
>
sudo
btrfs quota enable /サブボリュームのリストを取得します。
>
sudo
btrfs subvolume list /クォータは既存のサブボリュームにのみ設定できます。
前の手順で表示されたサブボリュームの1つにクォータを設定します。サブボリュームは、パス(
/var/tmp
など)または0/SUBVOLUME ID
(0/272
など)のどちらかによって識別できます。次に、/var/tmp
に5 GBのクォータを設定する例を示します。>
sudo
btrfs qgroup limit 5G /var/tmpサイズは、バイト(5000000000)、キロバイト(5000000K)、メガバイト(5000M)、またはギガバイト(5G)のいずれかの単位で指定できます。結果として得られるサイズは多少異なります。これは、1024バイト=1KiB、1024KiB=1MiBなどだからです。
既存のクォータを一覧にするには、次のコマンドを使用します。
max_rfer
列に、クォータがバイト単位で表示されます。>
sudo
btrfs qgroup show -r /
既存のクォータを無効にする場合、クォータサイズをnone
に設定します。
>
sudo
btrfs qgroup limit none /var/tmp
特定のパーティションとそのすべてのサブボリュームのクォータサポートを無効にするには、btrfs quota disable
を使用します。
>
sudo
btrfs quota disable /
1.2.5.3 詳細情報 #
詳細については、man 8 btrfs-qgroup
およびman 8
btrfs-quota
を参照してください。Btrfs wiki (UseCases)のhttps://btrfs.wiki.kernel.org/index.php/UseCasesページにも詳細情報が記載されています。
1.2.6 Btrfsでのスワッピング #
有効なスワップファイルがソースサブボリュームに含まれている場合、スナップショットを作成できません。
SLESでは、結果のスワップファイルに関連する次の条件が満たされている場合、Btrfsファイルシステム上のファイルへのスワッピングをサポートしています。
スワップファイルには
NODATACOW
およびNODATASUM
マウントオプションが必要です。スワップファイルは圧縮できません -
NODATACOW
およびNODATASUM
マウントオプションを設定することで、これを確認できます。両方のオプションにより、スワップファイルの圧縮が無効になります。スワップファイルは、デバイスのサイズ変更、追加、削除、置換などの排他的な操作の実行中、またはバランシング操作の実行中は有効にできません。
スワップファイルはスパースにすることはできません。
スワップファイルはインラインファイルにすることはできません。
スワップファイルは
single
割り当てプロファイルファイルシステム上にある必要があります。
1.2.7 Btrfs send/receive #
Btrfsでは、ファイルシステムの状態をキャプチャするためのスナップショットを作成できます。Snapperでは、たとえばこの機能を使用してシステムの変更前後のスナップショットを作成することで、ロールバックを可能にしています。ただし、send/receive機能とスナップショットを併用すると、リモートの場所にファイルシステムのコピーを作成して管理することもできます。たとえば、この機能を使用してインクリメンタルバックアップを実行できます。
btrfs send
操作は、同じサブボリュームの2つの読み込み専用スナップショットの差分を計算して、それをファイルまたはSTDOUTに送信します。btrfs receive
操作は、sendコマンドの結果を取得して、それをスナップショットに適用します。
1.2.7.1 前提条件 #
send/receive機能を使用するには、次の要件を満たす必要があります。
ソース側(
send
)とターゲット側(receive
)にBtrfsファイルシステムが必要です。Btrfs send/receiveはスナップショットを操作するため、それぞれのデータがBtrfsサブボリュームに存在する必要があります。
ソース側のスナップショットは読み込み専用である必要があります。
SUSE Linux Enterprise 12 SP2以上。それより古いバージョンのSUSE Linux Enterpriseはsend/receiveをサポートしていません。
1.2.7.2 インクリメンタルバックアップ #
次の手順では、/data
(ソース側)のインクリメンタルバックアップを/backup/data
(ターゲット側)に作成する場合を例にして、Btrfs send/receiveの基本的な使用方法を示します。/data
はサブボリュームである必要があります。
ソース側に初期スナップショット(この例では
snapshot_0
という名前)を作成し、それがディスクに書き込まれていることを確認します。>
sudo
btrfs subvolume snapshot -r /data /data/bkp_data sync新しいサブボリューム
/data/bkp_data
が作成されます。これは次のインクリメンタルバックアップの基として使用されるので、参照用に保持しておく必要があります。初期スナップショットをターゲット側に送信します。これは初期のsend/receive操作であるため、完全なスナップショットを送信する必要があります。
>
sudo
bash -c 'btrfs send /data/bkp_data | btrfs receive /backup'ターゲット側に新しいサブボリューム
/backup/bkp_data
が作成されます。
初期セットアップが完了したら、インクリメンタルバックアップを作成して、現在のスナップショットと以前のスナップショットの差分をターゲット側に送信できます。手順は常に同じです。
ソース側に新しいスナップショットを作成します。
差分をターゲット側に送信します。
オプション: 両側のスナップショットの名前変更またはクリーンアップ、あるいはその両方を行います。
ソース側に新しいスナップショットを作成し、それがディスクに書き込まれていることを確認します。次の例では、スナップショットにbkp_data_CURRENT_DATEという名前が付いています。
>
sudo
btrfs subvolume snapshot -r /data /data/bkp_data_$(date +%F) sync新しいサブボリューム(たとえば、
/data/bkp_data_2016-07-07
)が作成されます。以前のスナップショットと新たに作成したスナップショットの差分をターゲット側に送信します。そのためには、オプション
-p SNAPSHOT
を使用して、以前のスナップショットを指定します。>
sudo
bash -c 'btrfs send -p /data/bkp_data /data/bkp_data_2016-07-07 \ | btrfs receive /backup'新しいサブボリューム
/backup/bkp_data_2016-07-07
が作成されます。その結果、それぞれの側に2つずつ、合計4つのスナップショットが存在することになります。
/data/bkp_data
/data/bkp_data_2016-07-07
/backup/bkp_data
/backup/bkp_data_2016-07-07
続行するには、次の3つのオプションがあります。
両方の側のすべてのスナップショットを保持する。このオプションの場合、両方の側のどのスナップショットにもロールバックすることが可能であると同時に、すべてのデータの複製を保持していることになります。これ以上のアクションは必要ありません。次回のインクリメンタルバックアップを実行するときには、最後から2番目のスナップショットをsend操作の親として使用することに注意してください。
ソース側には最新のスナップショットのみを保持し、ターゲット側にはすべてのスナップショットを保持する。この場合も、両方の側のどのスナップショットにもロールバックできます。ソース側で特定のスナップショットへのロールバックを実行するには、ターゲット側からソース側に、完全なスナップショットのsend/receive操作を実行します。ソース側で削除/移動操作を実行します。
両方の側に最新のスナップショットのみを保持する。この方法では、ソース側で作成された最新のスナップショットと同じ状態のバックアップがターゲット側にあります。ほかのスナップショットにロールバックすることはできません。ソース側とターゲット側で削除/移動操作を実行します。
ソース側に最新のスナップショットのみを保持するには、次のコマンドを実行します。
>
sudo
btrfs subvolume delete /data/bkp_data>
sudo
mv /data/bkp_data_2016-07-07 /data/bkp_data最初のコマンドで以前のスナップショットを削除し、2番目のコマンドで現在のスナップショットの名前を
/data/bkp_data
に変更します。これにより、バックアップされた最新のスナップショットは常に/data/bkp_data
という名前になります。その結果、常にこのサブボリューム名をインクリメンタルsend操作の親として使用できます。ターゲット側に最新のスナップショットのみを保持するには、次のコマンドを実行します。
>
sudo
btrfs subvolume delete /backup/bkp_data>
sudo
mv /backup/bkp_data_2016-07-07 /backup/bkp_data最初のコマンドで以前のバックアップスナップショットを削除し、2番目のコマンドで現在のスナップショットの名前を
/backup/bkp_data
に変更します。これにより、最新のバックアップスナップショットは常に/backup/bkp_data
という名前になります。
スナップショットをリモートマシンに送信するには、SSHを使用します。
>
btrfs send /data/bkp_data | ssh root@jupiter.example.com 'btrfs receive /backup'
1.2.8 データ重複排除のサポート #
Btrfsはデータ重複排除をサポートします。そのための方法として、ファイルシステム内の複数の同一ブロックを、共通ストレージロケーションにある、そのブロックの1つのコピーを指す論理リンクで置き換えます。SUSE Linux Enterprise Serverでは、ファイルシステムをスキャンして同一ブロックをチェックするduperemove
ツールを提供しています。Btrfsファイルシステムで使用される場合、これらのブロックを重複排除して、ファイルシステムのスペースを節約することもできます。duperemove
はデフォルトではインストールされません。使用できるようにするには、パッケージduperemoveをインストールします。
大量のファイルを重複排除する場合は、--hashfile
オプションを使用します。
>
sudo
duperemove--hashfile HASH_FILE
file1 file2 file3
--hashfile
オプションは、すべての指定されたファイルのハッシュをRAMではなくHASH_FILEに保存して、使い果たされるのを防ぎます。HASH_FILEは再利用可能です。ベースラインハッシュファイルを生成した最初の実行後、大量のデータセットへの変更を非常に迅速に重複排除できます。
duperemove
は、ファイルのリストを処理することも、ディレクトリを再帰的にスキャンすることもできます。
>
sudo
duperemove OPTIONS file1 file2 file3>
sudo
duperemove -r OPTIONS directory
動作モードには、読み込み専用と重複排除の2つがあります。読み込み専用モードで実行した場合(-d
スイッチを指定しない)、指定されたファイルまたはディレクトリをスキャンして重複ブロックをチェックし、出力します。これは、どのファイルシステムでも機能します。
重複排除モードでのduperemove
の実行は、Btrfsファイルシステムでのみサポートされています。指定されたファイルまたはディレクトリをスキャンした後、重複しているブロックは重複排除用に送信されます。
詳細については、man 8 duperemove
を参照してください。
1.2.9 ルートファイルシステムからのサブボリュームの削除 #
特定の目的のためにルートファイルシステムからデフォルトのBtrfsサブボリュームの1つを削除する必要がある場合があります。それらの1つはサブボリューム、たとえば@/home
または@/srv
を別のデバイスのファイルシステムに変換します。次の手順は、Btrfsサブボリュームを削除する方法を示しています。
削除する必要のあるサブボリュームを特定します(たとえば、
@/opt
)。ルートパスのサブボリュームIDが常に「5」であることに注意してください。>
sudo
btrfs subvolume list / ID 256 gen 30 top level 5 path @ ID 258 gen 887 top level 256 path @/var ID 259 gen 872 top level 256 path @/usr/local ID 260 gen 886 top level 256 path @/tmp ID 261 gen 60 top level 256 path @/srv ID 262 gen 886 top level 256 path @/root ID 263 gen 39 top level 256 path @/opt [...]ルートパーティションをホストするデバイス名を見つけます:。
>
sudo
btrfs device usage / /dev/sda1, ID: 1 Device size: 23.00GiB Device slack: 0.00B Data,single: 7.01GiB Metadata,DUP: 1.00GiB System,DUP: 16.00MiB Unallocated: 14.98GiBルートファイルシステム(ID 5のサブボリューム)を別のマウントポイント(たとえば
/mnt
)上にマウントします。>
sudo
mount -o subvolid=5 /dev/sda1 /mntマウントされたルートファイルシステムから
@/opt
パーティションを削除します。>
sudo
btrfs subvolume delete /mnt/@/opt以前にマウントされたルートファイルシステムをアンマウントします:。
>
sudo
umount /mnt
1.3 XFS #
本来は、IRIX OS用のファイルシステムを意図してSGIがXFSの開発を開始したのは、1990年代初期です。XFSの開発動機は、ハイパフォーマンスの64ビットジャーナルファイルシステムの作成により、非常に厳しいコンピューティングの課題に対応することでした。XFSは大規模なファイルを操作する点で非常に優れていて、ハイエンドのハードウェアを適切に活用します。XFSは、SUSE Linux Enterprise Serverのデータパーティション用のデフォルトファイルシステムです。
ただし、XFSの主要機能を一見すれば、XFSが、ハイエンドコンピューティングの分野で、他のジャーナリングファイルシステムの強力な競合相手となっている理由がわかります。
- 高いスケーラビリティ
XFSはアロケーショングループを使用して高いスケーラビリティを実現する
XFSファイルシステムの作成時に、ファイルシステムの基にあるブロックデバイスは、等しいサイズをもつ8つ以上の線形の領域に分割されます。これらを「アロケーショングループ」と呼びます。各アロケーショングループは、独自のinodeと空きディスクスペースを管理します。実用的には、アロケーショングループを、1つのファイルシステムの中にある複数のファイルシステムと見なすこともできます。アロケーショングループは互いに独立しているものではないため、複数のアロケーショングループをカーネルから同時にアドレス指定できるという特徴があります。この機能は、XFSの高いスケーラビリティに大きく貢献しています。独立性の高いアロケーショングループは、性質上、マルチプロセッサシステムのニーズに適しています。
- 高いパフォーマンス
XFSはディスクスペースの効率的な管理によって高いパフォーマンスを実現する
空きスペースとinodeは、各アロケーショングループ内のB+-Treeによって処理されます。B+ツリーの採用は、XFSのパフォーマンスとスケーラビリティを大きく向上させています。XFSでは、プロセスを2分割して割り当てを処理する遅延割り当てを使用します。保留されているトランザクションはRAMの中に保存され、適切な量のスペースが確保されます。XFSは、この時点では、データを正確にはどこに(ファイルシステムのどのブロックに)格納するか決定していません。決定可能な最後の瞬間まで、この決定は遅延(先送り)されます。暫定的に使用される一時データは、ディスクに書き込まれません。XFSがデータの保存場所を決定するまでに、その役割を終えているからです。このように、XFSは、書き込みのパフォーマンスを向上させ、ファイルシステムのフラグメンテーションを減少させます。遅延アロケーションは、他のファイルシステムより書き込みイベントの頻度を下げる結果をもたらすので、書き込み中にクラッシュが発生した場合、データ損失が深刻になる可能性が高くなります。
- 事前割り当てによるファイルシステムの断片化の回避
データをファイルシステムに書き込む前に、XFSはファイルが必要とする空きスペースを予約(プリアロケート、事前割り当て)します。したがって、ファイルシステムの断片化は大幅に減少します。ファイルの内容がファイルシステム全体に分散することがないので、パフォーマンスが向上します。
1.3.1 XFSフォーマット #
SUSE Linux Enterprise Serverは、XFSファイルシステムの「オンディスクフォーマット」(v5)をサポートしています。このフォーマットの主な利点には、全XFSメタデータの自動チェックサム、ファイルタイプのサポート、および1つのファイルに対する大量のアクセス制御リストのサポートがあります。
このフォーマットは、SUSE Linux Enterpriseカーネルの3.12より古いバージョン、xfsprogs
の3.2.0より古いバージョン、およびSUSE Linux Enterprise 12より前にリリースされたバージョンのGRUB 2ではサポートされていません。
XFSではV4フォーマットのファイルシステムが非推奨になっています。このファイルシステムフォーマットは次のコマンドで作成されました。
mkfs.xfs -m crc=0 DEVICE
このフォーマットはSLE 11以前のリリースで使用されましたが、現在このフォーマットを使用するとdmesg
によって次の警告メッセージが表示されます。
Deprecated V4 format (crc=0) will not be supported after September 2030
dmesg
コマンドの出力に上記のメッセージが表示されたら、ファイルシステムをV5フォーマットに更新することをお勧めします。
データを別のデバイスにバックアップします。
そのデバイスにファイルシステムを作成します。
mkfs.xfs -m crc=1 DEVICE
更新したデバイスにバックアップからデータを復元します。
1.4 Ext2 #
Ext2の起源は、Linuxの歴史の初期にさかのぼります。その前身であったExtended File Systemは、1992年4月に実装され、Linux 0.96cに統合されました。Extended File Systemにはさまざまな変更が加えられてきました。そして、Ext2はLinuxファイルシステムとして数年にわたり非常に高い人気を得ています。その後、ジャーナルファイルシステムが作成され、回復時間が非常に短くなったため、Ext2の重要性は低下しました。
Ext2の利点に関する短い要約を読むと、かつて幅広く好まれ、そして今でも一部の分野で多くのLinuxユーザから好まれるLinuxファイルシステムである理由を理解するのに役立ちます。
- 堅実性と速度
「古くからある標準」であるExt2は、さまざまな改良が加えられ、入念なテストが実施されてきました。だからこそ、Ext2は非常に信頼性が高いとの評価を得ることが多いのでしょう。ファイルシステムが正常にアンマウントできず、システムが機能停止した場合、e2fsckはファイルシステムのデータの分析を開始します。メタデータは一貫した状態に戻り、保留されていたファイルとデータブロックは、指定のディレクトリ(
lost+found
)に書き込まれます。ジャーナルファイルシステムとは対照的に、e2fsckは、最近変更されたわずかなメタデータだけではなく、ファイルシステム全体を分析します。この結果、ジャーナルファイルシステムがログデータだけをチェックするのに比べて、かなり長い時間を要します。ファイルシステムのサイズにもよりますが、この手順は30分またはそれ以上を要することがあります。したがって、高可用性を必要とするどのようなサーバでも、Ext2を選択することは望ましくありません。ただし、Ext2はジャーナルを維持せず、わずかなメモリを使用するだけなので、他のファイルシステムより高速なことがあります。- 容易なアップグレード性
Ext3は、Ext2のコードをベースとし、Ext2のオンディスクフォーマットとメタデータフォーマットも共用するので、Ext2からExt3へのアップグレードは非常に容易です。
1.5 Ext3 #
Ext3は、Stephen Tweedieによって設計されました。他のすべての次世代ファイルシステムとは異なり、Ext3は完全に新しい設計理念に基づいているわけではありません。Ext3は、Ext2をベースとしています。これら2つのファイルシステムは、非常に似ています。Ext3ファイルシステムを、Ext2ファイルシステムの上に構築することも容易です。Ext2とExt3の最も重要な違いは、Ext3がジャーナルをサポートしていることです。要約すると、Ext3には、次の3つの主要な利点があります。
1.5.1 Ext2からの容易で信頼性の高いアップグレード #
Ext2のコードは、Ext3が次世代ファイルシステムであることを明確に主張するための強力な土台になりました。Ext3では、Ext2の信頼性および堅実性がExt3で採用されたジャーナルファイルシステムの利点とうまく統合されています。XFSのような他のジャーナリングファイルシステムへの移行はかなり手間がかかります(ファイルシステム全体のバックアップを作成し、移行先ファイルシステムを新規に作成する必要があります)が、それとは異なり、Ext3への移行は数分で完了します。ファイルシステム全体を新たに作成し直しても、それが完璧に動作するとは限らないので、Ext3への移行は非常に安全でもあります。ジャーナルファイルシステムへのアップグレードを必要とする既存のExt2システムの数を考慮に入れると、多くのシステム管理者にとってExt3が重要な選択肢となり得る理由が容易にわかります。Ext3からExt2へのダウングレードも、アップグレードと同じほど容易です。Ext3ファイルシステムのアンマウントを正常に行い、Ext2ファイルシステムとして再マウントします。
1.5.2 Ext2ファイルシステムからExt3への変換 #
Ext2ファイルシステムをExt3に変換するには、次の手順に従います。
Ext3ジャーナルの作成には、
tune2fs -j
をroot
ユーザとして実行します。この結果、デフォルトのパラメータを使用してExt3ジャーナルが作成されます。
ジャーナルのサイズおよびジャーナルを常駐させるデバイスを指定するには、
tune2fs
-J
とともに適切なジャーナルオプションsize=
およびdevice=
を指定して、実行します。tune2fs
プログラムの詳細については、tune2fs
のマニュアルページを参照してください。ファイル
/etc/fstab
をroot
ユーザとして編集して、該当するパーティションに指定されているファイルシステムタイプをext2
からext3
に変更し、その変更内容を保存します。これにより、Ext3ファイルシステムが認識されるようになります。この変更結果は、次回の再起動後に有効になります。
Ext3パーティションとしてセットアップされたルートファイルシステムをブートするには、
ext3
とjbd
の各モジュールをinitrd
に追加します。それには、次を実行します。/etc/dracut.conf.d/filesystem.conf
を開くか作成し、次の行を追加します(行頭空白に注意してください):force_drivers+=" ext3 jbd"
dracut
-f
コマンドを実行します。
システムを再起動します。
1.6 Ext4 #
2006年に、Ext4はExt3の後継として登場しました。これは、拡張ファイルシステムバージョンの最新ファイルシステムです。当初、最大1エクスビバイトのサイズのボリューム、最大16テビバイトのサイズのファイルおよび無制限の数のサブディレクトリをサポートすることによってストレージサイズを拡大するために、Ext4は設計されました。Ext4では、従来の直接ブロックポインタおよび間接ブロックポインタの代わりにエクステントを使用してファイルの内容をマップします。エクステントの使用によって、ディスクにおけるデータ格納とデータ取得の両方が改善されています。
同時に、遅延ブロック割り当て、ファイルシステムチェックルーチンの大幅な高速化など、さまざまなパフォーマンス強化も図られています。また、Ext4は、ジャーナルチェックサムのサポートおよびナノ秒単位でのタイムスタンプの提供により、信頼性を高めています。Ext4には、Ext2およびExt3との完全な後方互換性があり、どちらのファイルシステムもExt4としてマウントできます。
Ext3の機能は、Ext4カーネルモジュールのExt4ドライバによって完全にサポートされます。
1.6.1 信頼性とパフォーマンス #
他のジャーナルファイルシステムは、「メタデータのみ」のジャーナルアプローチに従っています。つまり、メタデータは常に一貫した状態に保持されますが、ファイルシステムのデータ自体については、一貫性が自動的に保証されるわけではありません。Ext4は、メタデータとデータの両方に注意するよう設計されています。「注意」の度合いはカスタマイズできます。data=journal
モードでExt4をマウントすると、最大の保護(データの完全性)が実現されますが、メタデータとデータの両方がジャーナル化されるので、システムの動作が遅くなります。別のアプローチは、data=ordered
モードを使用することです。これは、データとメタデータ両方の完全性を保証しますが、ジャーナルを適用するのはメタデータのみです。ファイルシステムドライバは、1つのメタデータの更新に対応するすべてのデータブロックを収集します。これらのブロックは、メタデータの更新前にディスクに書き込まれます。その結果、パフォーマンスを犠牲にすることなく、メタデータとデータの両方に関する一貫性を達成できます。3番目のマウントオプションは、data=writeback
を使用することです。これは、対応するメタデータをジャーナルにコミットした後で、データをメインファイルシステムに書き込むことを可能にします。多くの場合、このオプションは、パフォーマンスの点で最善と考えられています。しかし、内部のファイルシステムの完全性が維持される一方で、クラッシュと回復を実施した後では、古いデータがファイル内に再登場させてしまう可能性があります。Ext4では、デフォルトとして、data=ordered
オプションを使用します。
1.6.2 Ext4ファイルシステムのinodeサイズとinode数 #
inodeには、ファイルシステム内のファイルとそのブロック位置に関する情報が格納されます。拡張された属性およびACL用にinodeのスペースを確保するために、デフォルトのinodeサイズが256バイトに拡大されました。
新規のExt4ファイルシステムを作成する際、inodeテーブル内のスペースは、作成可能なinodeの総数に対して事前に割り当てられています。バイト数/inode数の比率と、ファイルシステムのサイズによって、inode数の上限が決まります。ファイルシステムが作成されると、バイト数/inode数のバイト数の各スペースに対して、1つのinodeが作成されます。
number of inodes = total size of the file system divided by the number of bytes per inode
inodeの数によって、ファイルシステム内に保有できるファイルの数が決まります。つまり、各ファイルにつき1つのinodeです。
inodeの割り当て後は、inodeサイズやバイト数/inode数の比率の設定を変えることはできません。異なる設定のファイルシステムを再度作成するか、ファイルシステムを拡張しない限り、新規のinodeは設定できません。inodeの最大数を超えると、ファイルをいくつか削除するまで、ファイルシステム上に新規のファイルを作成することはできません。
新規のExt4ファイルシステムを作成する際に、inodeのスペース使用をコントロールするためのinodeサイズとバイト数/inode数の比率、およびファイルシステム上のファイル数の上限を指定することができます。ブロックサイズ、inodeサイズ、およびバイト数/inode数の比率が指定されない場合は、/etc/mked2fs.conf
ファイル内のデフォルト値が適用されます。詳細については、mke2fs.conf(5)
マニュアルページを参照してください。
次のガイドラインを使用します。
inodeサイズ. デフォルトのinodeサイズは256バイトです。2の累乗で、ブロックサイズ以下の128以上のバイト数の値を指定します(128、256、512など)。Ext4ファイルシステムで拡張属性またはACLを使用しない場合は、128バイトのみを使用してください。
バイト数/inode数の比率: デフォルトのバイト数/inode数の比率は、16384バイトです。有効なバイト数/inode数の比率は、2の累乗で1024バイト以上(1024、2048、4096、8192、16384、32768など)です。この値は、ファイルシステムのブロックサイズより小さくはできません。なぜなら、ブロックサイズは、データを格納するために使用するスペースの最小チャンクだからです。Ext4ファイルシステムのデフォルトのブロックサイズは、4KiBです。
また、格納する必要があるファイルの数とサイズを検討してください。たとえば、ファイルシステムに多数の小さなファイルを持つことになる場合は、バイト数/inode数の比率を小さめに指定すれば、inodeの数を増やすことができます。ファイルシステムに非常に大きなファイルを入れる場合は、バイト数/inode数の比率を大きめに指定できますが、それによって許容されるinodeの数は減ります。
一般的に、inodeの数は、足りなくなるよりは多すぎる方が得策です。inodeの数が少な過ぎてファイルも非常に小さい場合、実際には空であってもディスク上のファイルの最大数に到達してしまいます。inodeの数が多すぎて、ファイルが非常に大きい場合は、空き領域があることが表示されたとしても、それを使うことができません。なぜなら、inode用に確保されたスペースに新規のファイルを作成することはできないからです。
inodeサイズとバイト数/inode数の比率を設定するには、次のいずれかの方法を使用します。
すべての新規Ext4ファイルシステムのデフォルト設定を変更する: テキストエディタで、
/etc/mke2fs.conf
ファイルのdefaults
セクションを変更して、inode_size
およびinode_ratio
を、希望するデフォルト値に設定します。その値が、すべての新規のExt4ファイルシステムに適用されます。例:blocksize = 4096 inode_size = 128 inode_ratio = 8192
コマンドラインで: 新しいExt4ファイルシステムを作成する際に、inodeサイズ(
-I 128
)およびバイト数/inode数の比率(-i 8192
)を、mkfs.ext4(8)
コマンドまたはmke2fs(8)
コマンドに渡します。たとえば、次のコマンドのいずれかを使用します:。>
sudo
mkfs.ext4 -b 4096 -i 8092 -I 128 /dev/sda2>
sudo
mke2fs -t ext4 -b 4096 -i 8192 -I 128 /dev/sda2YaSTを使用したインストール時に: インストール時に新規のExt4ファイルシステムを作成する際に、inodeサイズとバイト数/inode数の比率を渡します。 で、パーティションを選択して、 をクリックします。 で、 を選択し、 をクリックします。 ダイアログで、 、 、および ドロップダウンボックスから、希望の値を選択します。
たとえば、
ドロップダウンボックスから4096を選択し ドロップダウンボックスから8192を選択し、 ドロップダウンボックスから128を選択して、 をクリックします。
1.6.3 Ext4へのアップグレード #
ファイルシステムの更新を実行する前に、ファイルシステムにあるすべてのデータをバックアップします。
Ext2またはExt3からアップグレードするには、以下を有効にする必要があります。
Ext4で必要な機能 #- エクステント
各ファイルを近くに保持して断片化を防ぐために使用されるハードディスク上の連続ブロック
- unint_bg
遅延inodeテーブルの初期化
- dir_index
大きいディレクトリ用のハッシュされたbツリー検索
- Ext2:
as_journal
Ext2ファイルシステムでジャーナリングを有効にします。
これらの機能を有効にするには、次のコマンドを実行します。
Ext3:
#
tune2fs -O extents,uninit_bg,dir_index DEVICE_NAMEExt2:
#
tune2fs -O extents,uninit_bg,dir_index,has_journal DEVICE_NAME
root
によって/etc/fstab
ファイルが編集されるとき、ext3
またはext2
のレコードをext4
に変更します。この変更結果は、次回の再起動後に有効になります。Ext4パーティションでセットアップされたファイルシステムをブートするには、
ext4
とjbd
の各モジュールをinitramfs
に追加します。/etc/dracut.conf.d/filesystem.conf
を開くか作成し、次の行を追加します。force_drivers+=" ext4 jbd"
既存のdracut
initramfs
を上書きする必要があります。そのためには、次のコマンドを実行します。dracut -f
システムを再起動します。
1.7 ReiserFS #
ReiserFSのサポートは、SUSE Linux Enterprise Server 15で廃止されました。既存のパーティションをBtrfsにマイグレートするには、1.2.3項 「ReiserFSおよびExtの各ファイルシステムからBtrfsへのマイグレーション」を参照してください。
1.8 OpenZFSとZFS #
OpenZFSファイルシステムもZFSファイルシステムもSUSEではサポートされていません。ZFSは閉じられたソースファイルシステムであるため、SUSEでは使用できません。OpenZFSは、GPLライセンスと互換性のないCDDLライセンスの下にあります。ただし、BtrfsにはOpenZFS respのすばらしい代替品があります。ZFSはSUSEによって完全にサポートされています。
1.9 サポートされている他のファイルシステム #
表1.1「Linux環境でのファイルシステムのタイプ」は、Linuxがサポートしている他のいくつかのファイルシステムを要約したものです。これらは主に、他の種類のメディアや外部オペレーティングシステムとの互換性およびデータの相互交換を保証することを目的としてサポートされています。
ファイルシステムのタイプ |
説明 |
---|---|
|
CD-ROMの標準ファイルシステム。 |
|
|
|
Network File System (ネットワークファイルシステム) :ネットワーク内の任意のコンピュータにデータを格納でき、ネットワーク経由でアクセスを付与できます。 |
|
Windows NT file system (NTファイルシステム) :読み取り専用です。 |
|
USBフラッシュドライブやSDカードなど、フラッシュメモリで使用するために最適化されたファイルシステムです。 |
|
Server Message Block (サーバメッセージブロック): Windowsのような製品が、ネットワーク経由でのファイルアクセスを可能にする目的で採用しています。 |
|
BSD、SunOS、およびNextStepで使用されています。読み取り専用モードでサポートされています。 |
|
UNIX on MS-DOS(MS-DOS上のUNIX) - 標準 |
|
Virtual FAT: |
1.10 ブロックされるファイルシステム #
セキュリティ上の理由によって、自動マウントからブロックされるファイルシステムがあります。これらのファイルシステムは通常維持されなくなり、一般的に使用されません。ただし、このファイルシステムのカーネルモジュールをロードできます。これは、カーネル内のAPIの互換性が保たれているためです。ユーザがマウントできるファイルシステムとファイルシステムの自動マウントを取り外し可能デバイスで組み合わせると、特権のないユーザがカーネルモジュールの自動ロードをトリガする状況が発生し、悪意のあるデータが取り外し可能デバイスに格納される危険性があります。
自動マウントが許可されていないファイルシステムのリストを取得するには、次のコマンドを実行します。
>
sudo
rpm -ql suse-module-tools | sed -nE 's/.*blacklist_fs-(.*)\.conf/\1/p'
mount
コマンドを使用してブロックされるファイルシステムでデバイスをマウントしようとすると、このコマンドはエラーメッセージを出力します。次に例を示します。
mount: /mnt/mx: unknown filesystem type 'minix' (hint: possibly blacklisted, see mount(8)).
ファイルシステムのマウントを有効にするには、ブロックリストからそのファイルシステムを削除する必要があります。ブロックされるファイルシステムそれぞれに独自の設定ファイルがあります。たとえば、efs
では/lib/modules.d/60-blacklist_fs-efs.conf
です。ただし、suse-module-tools
パッケージが更新されると、これらのファイルは必ず上書きされるため、編集しないでください。ブロックされるファイルシステムの自動マウントを許可するには、次の方法があります。
/dev/null
ヘのシンボリックリンクを作成します。たとえば、efsファイルシステムの場合には次のようにします。>
sudo
ln -s /dev/null /etc/modules.d/60-blacklist_fs-efs.conf設定ファイルを
/etc/modprobe.d
にコピーします。>
sudo
cp /lib/modules.d/60-blacklist_fs-efs.conf /etc/modprobe.d/60-blacklist_fs-efs.conf設定ファイルの次のステートメントをコメントにします。
# blacklist omfs
ファイルシステムを自動マウントできない場合でも、modprobe
を直接使用して、そのファイルシステムの対応するカーネルモジュールをロードできます。
>
sudo
modprobe FILESYSTEM
たとえば、cramfs
ファイルシステムの場合、出力は次のようになります。
unblacklist: loading cramfs file system module unblacklist: Do you want to un-blacklist cramfs permanently (<y>es/<n>o/n<e>ver)? y unblacklist: cramfs un-blacklisted by creating /etc/modprobe.d/60-blacklist_fs-cramfs.conf
yesを選択すると、modprobe
コマンドは、指定したファイルシステムの設定ファイルからシンボリックリンクを作成するスクリプトを/dev/null
に呼び出します。したがって、このファイルシステムはブロックリストから削除されます。
1.11 Linux環境での大規模ファイルサポート #
当初、Linuxは、最大ファイルサイズとして 2GiB (231バイト)をサポートしていました。また、ファイルシステムに大規模ファイルサポートが付いていない限り、32ビットシステム上での最大ファイルサイズは2GiBです。
現在、弊社のすべての標準ファイルシステムでは、LFS (大規模ファイルサポート)を提供しています。LFSは、理論的には、263バイトの最大ファイルサイズをサポートします。表1.2「ファイルおよびファイルシステムの最大サイズ(オンディスクフォーマット、4KiBブロックサイズ)」では、Linuxのファイルとファイルシステムの、現行のオンディスクフォーマットの制限事項を概説しています。表内の数字は、ファイルシステムで使用しているブロックサイズが、共通規格である4KiBであることを前提としています。異なるブロックサイズを使用すると結果は異なります。スパースブロックを使用している場合、表1.2「ファイルおよびファイルシステムの最大サイズ(オンディスクフォーマット、4KiBブロックサイズ)」に記載の最大ファイルサイズは、ファイルシステムの実際のサイズより大きいことがあります。
このマニュアルでの換算式: 1024バイト = 1KiB、1024KiB = 1MiB、1024MiB = 1 GiB、1024GiB = 1TiB、1024TiB = 1PiB、1024PiB = 1EiB (「NIST: Prefixes for Binary Multiples」も参照してください)。
ファイルシステム(4KiBブロックサイズ) |
ファイルシステムの最大サイズ |
ファイルの最大サイズ |
---|---|---|
Btrfs |
16EiB |
16EiB |
Ext3 |
16TiB |
2TiB |
Ext4 |
1EiB |
16TiB |
OCFS2 (High Availability Extensionで使用可能な、クラスタ認識のファイルシステム) |
16TiB |
1EiB |
XFS |
16EiB |
8EiB |
NFSv2 (クライアント側) |
8EiB |
2GiB |
NFSv3/NFSv4 (クライアント側) |
8EiB |
8EiB |
表1.2「ファイルおよびファイルシステムの最大サイズ(オンディスクフォーマット、4KiBブロックサイズ)」は、ディスクフォーマット時の制限について説明しています。Linuxカーネルは、操作するファイルとファイルシステムのサイズについて、独自の制限を課しています。管理の初期設定には、次のオプションがあります。
- ファイルサイズ
32ビットシステムでは、ファイルサイズが2TiB (241バイト)を超えることはできません。
- ファイルシステムのサイズ
ファイルシステムのサイズは、最大273バイトまで可能です。しかし、この制限は、現在使用可能なハードウェアが到達可能な範囲を上回っています。
1.12 Linuxのカーネルにおけるストレージの制限 #
表1.3「ストレージの制限」に、SUSE Linux Enterprise Serverに関連したストレージに関するカーネルの制限をまとめています。
ストレージの機能 |
制限 |
---|---|
サポートされるLUNの最大数 |
ターゲットあたり16384 LUN。 |
単一LUNあたりのパスの最大数 |
デフォルトで無制限。それぞれのパスが、通常のLUNとして扱われます。 実際の制限は、ターゲットあたりのLUNの数と、HBAあたりのターゲットの数(ファイバチャネルHBAの場合は16777215)により決まります。 |
HBAの最大数 |
無制限.実際の制限は、システムのPCIスロットの量で決まります。 |
オペレーティングシステムあたりの、デバイスマッパーマルチパス付きパスの最大数(合計) |
約1024。実際の数は、各マルチパスデバイスのデバイス番号文字列の長さによって異なります。これはマルチパスツール内のコンパイル時変数であり、この制限が問題となる場合は増やすこともできます。 |
最大サイズ(ブロックデバイスごと) |
最大8EiB。 |
1.13 未使用のファイルシステムブロックの解放 #
SSD(Solid-State Drive)およびシンプロビジョニングされたボリュームでは、ファイルシステムによって使用されていないブロックに対してTrimを実行すると効果的です。SUSE Linux Enterprise Serverは、unmap
およびTRIM
の操作をサポートするすべてのファイルシステムで、これらの操作を完全にサポートします。
2つのタイプの一般的に使用されるTRIM(オンラインTRIM
と定期TRIM
)があります。デバイスをトリムする最も適切な方法は使用例によって異なります。一般的に、定期TRIMの使用をお勧めします(特に、デバイスに十分な未使用ブロックがある場合)。デバイスの容量が一杯に近くなることが多い場合はオンラインTRIMをお勧めします。
TRIM
のサポート
TRIM
を使用する前に、デバイスがこの操作をサポートしていることを必ず確認してください。確認を怠ると、そのデバイスのデータが喪失する危険性があります。TRIM
のサポートを確認するには、次のコマンドを実行します。
>
sudo
lsblk --discard
このコマンドを実行すると、使用可能なすべてのブロックデバイスに関する情報が出力されます。DISC-GRAN
列およびDISC-MAX
列の値がゼロ以外の場合、デバイスはTRIM
操作をサポートしています。
1.13.1 定期TRIM #
定期TRIMは、定期的にsystemd
によって呼び出されるfstrim
コマンドによって処理されます。コマンドを手動で実行することもできます。
定期TRIMをスケジュールするには、次のようにfstrim.timer
を有効にします。
>
sudo
systemctl enable fstrim.timer
systemd
は/usr/lib/systemd/system
にユニットファイルを作成します。デフォルトでは、このサービスは1週間に1回実行されます。通常はこれで十分です。ただし、OnCalendar
オプションを目的の値に設定することによって頻度を変更できます。
fstrim
のデフォルト動作は、ファイルシステムですべてのブロックを破棄することです。コマンドを呼び出すときにオプションを使用してこの動作を変更できます。たとえば、offset
オプションを渡してトリミング手順の開始地点を定義できます。詳細については、man fstrim
を参照してください。
fstrim
コマンドを実行すると、/etc/fstab
ファイルに保存されているすべてのデバイスでトリミングを実行できます。これはTRIM
操作をサポートしています。この目的でコマンドを呼び出すときには-A
オプションを使用します。
特定のデバイスのトリミングを無効にするには、次のようにX-fstrim.notrim
オプションを/etc/fstab
ファイルに追加します。
UID=83df497d-bd6d-48a3-9275-37c0e3c8dc74 / btrfs defaults,X-fstrim.notrim 0 0
1.13.2 オンラインTRIM #
デバイスのオンラインTRIMは、デバイスにデータを書き込むたびに実行されます。
デバイスのオンラインTRIMを有効にするには、次のようにdiscard
オプションを/etc/fstab
ファイルに追加します。
UID=83df497d-bd6d-48a3-9275-37c0e3c8dc74 / btrfs defaults,discard
また、Ext4ファイルシステムでtune2fs
コマンドを使用して/etc/fstab
にdiscard
オプションを設定します。
>
sudo
tune2fs -o discard DEVICE
discard
オプションを指定してmount
によってデバイスがマウントされた場合も、discard
オプションは/etc/fstab
に追加されます。
>
sudo
mount -o discard DEVICE
discard
オプションを使用すると、一部の低品質SSDデバイスの寿命が短くなる場合があります。オンラインTRIMによってデバイスのパフォーマンスに悪影響が及ぶ場合もあります(大量のデータが削除される場合など)。この状況では、消去ブロックが再割り当てされ、そのすぐ後に同じ消去ブロックが未使用として再度マークされる場合があります。
1.14 ファイルシステムのトラブルシューティング #
本項では、ファイルシステムに関するいくつかの既知の問題と、考えられる解決手段について説明します。
1.14.1 Btrfsエラー: デバイスに空き領域がない #
Btrfsファイルシステムを使用しているルート(/
)パーティションにデータを書き込めなくなります。「No space left
on device
」というエラーが発生します。
考えられる原因とこの問題の回避策については、この後の各項を参照してください。
1.14.1.1 Snapperスナップショットによるディスク容量の使用 #
BtrfsファイルシステムでSnapperが動作している場合、「No
space left on device
」が表示される問題は、通常は、システム上にスナップショットとして保存されているデータが多すぎるために発生します。
Snapperからいくつかのスナップショットを削除することはできますが、スナップショットはすぐには削除されないので、必要な容量が解放されない可能性があります。
Snapperからファイルを削除するには:
端末を開きます。
コマンドプロンプトで、たとえば「
btrfs filesystem show
」と入力します。>
sudo
btrfs filesystem show Label: none uuid: 40123456-cb2c-4678-8b3d-d014d1c78c78 Total devices 1 FS bytes used 20.00GB devid 1 size 20.00GB used 20.00GB path /dev/sda3以下を入力してください。
>
sudo
btrfs fi balance start MOUNTPOINT -dusage=5このコマンドは、データを空またはほぼ空のデータチャンクに再配置して、その容量を回収し、メタデータに再割り当てしようとします。この処理にはしばらくかかります(1 TBで数時間)が、処理中もシステムは使用可能です。
Snapperのスナップショットを一覧にします。以下を入力してください。
>
sudo
snapper -c root listSnapperから1つ以上のスナップショットを削除します。以下を入力してください。
>
sudo
snapper -c root delete SNAPSHOT_NUMBER(S)必ず最も古いスナップショットを最初に削除してください。古いスナップショットほど、多くの容量を使用します。
この問題が発生しないように、Snapperのクリーンアップアルゴリズムを変更できます。詳細については10.6.1.2項 「クリーンアップアルゴリズム」を参照してください。スナップショットクリーンアップを制御する設定値は、EMPTY_*
、NUMBER_*
、およびTIMELINE_*
です。
ファイルシステムディスクでBtrfsとSnapperを使用する場合、標準のストレージ案の2倍のディスク容量を確保しておくことが推奨されます。YaSTパーティショナは、ルートファイルシステムでBtrfsを使用する場合のストレージ案として、自動的に標準の2倍のディスク容量を提案します。
1.14.1.2 ログ、クラッシュ、およびキャッシュのファイルによるディスク容量の使用 #
システムディスクがデータでいっぱいになりつつある場合、/var/log
、/var/crash
、/var/lib/systemd/coredump
および/var/cache
からファイルを削除する方法があります。
Btrfs root
ファイルシステムのサブボリューム/var/log
、/var/crash
および/var/cache
が、通常の操作時に利用可能なディスクスペースのすべてを使用でき、システムに不具合が発生します。この状況を回避するため、SUSE Linux Enterprise Serverではサブボリュームに対するBtrfsクォータのサポートを提供するようになりました。詳細については1.2.5項 「サブボリュームに対するBtrfsクォータのサポート」を参照してください。
テストおよび開発用のマシンでは、特にアプリケーションが頻繁にクラッシュする場合、コアダンプが保存されている/var/lib/systemd/coredump
を確認することもできます。
1.14.2 Btrfs: デバイス間でデータのバランスを取る #
btrfs balance
コマンドは、btrfs-progsパッケージの一部です。次の状況例では、Btrfsファイルシステムのブロックグループのバランスを取ります。
600GBをデータで使用される1TBのドライブがあり、さらに1TBドライブを追加するとします。バランスを取ることで、理論的には、各ドライブに300GBの使用済みスペースができます。
デバイスには空に近い多数のチャンクがあります。バランスを取ることによりこれらのチャンクがクリアされるまで、それらのスペースは利用できません。
使用率に基づいて半分空のブロックグループを圧縮する必要があります。次のコマンドは、使用率が5%以下のブロックグループのバランスを取ります。
>
sudo
btrfs balance start -dusage=5 /ヒント/usr/lib/systemd/system/btrfs-balance.timer
タイマによって、未使用ブロックグループが毎月クリーンアップされます。ブロックデバイスのフルでない部分をクリアし、データをより均等に分散する必要があります。
異なるRAIDタイプ間でデータを移行する必要があります。たとえば、一連のディスク上のデータをRAID1からRAID5に変換するには、次のコマンドを実行します。
>
sudo
btrfs balance start -dprofiles=raid1,convert=raid5 /
Btrfsファイルシステム上のデータのバランスを取るデフォルトの動作(たとえば、バランスを取る頻度やマウントポイント)を微調整するには、/etc/sysconfig/btrfsmaintenance
を検査してカスタマイズします。関連するオプションは、BTRFS_BALANCE_
_で開始されます。
btrfs balance
コマンドの使用に関する詳細については、そのマニュアルページ(man 8 btrfs-balance
)を参照してください。
1.14.3 SSDでデフラグメンテーションしない #
Linuxファイルシステムには、データフラグメンテーションを回避するメカニズムがあり、通常はデフラグメントする必要はありません。ただし、データフラグメンテーションを回避できない場合、およびハードディスクのデフラグメンテーションによってパフォーマンスが大幅に向上する場合に使用するケースがあります。
これは従来のハードディスクにのみ適用されます。フラッシュメモリを使用してデータを保存するソリッドステートディスク(SSD)では、ファームウェアによってデータを書き込むチップを判断するアルゴリズムが提供されます。データは通常、ドライブ全体に分散されます。したがって、SSDのデフラグメンテーションは望ましい効果がなく、不要なデータを書き込むことにより、SSDの製品寿命を縮めます。
この理由のため、SUSEではSSDでデフラグメントしないことを明示的にお勧めします。一部のベンダーも、ソリッドステートディスクをデフラグメントすることについて警告しています。これには、次のものが含まれますが、これに限定されません。
HPE 3PAR StoreServオールフラッシュ
HPE 3PAR StoreServコンバージドフラッシュ
1.15 詳細情報 #
ここまでに説明した各ファイルシステムのプロジェクトには、独自のWebページがあります。そこで詳しいドキュメントとFAQ、さらにメーリングリストを参照することができます。
Kernel.orgのBtrfs Wiki: https://btrfs.wiki.kernel.org/
E2fsprogs: Ext2/3/4 File System Utilities: http://e2fsprogs.sourceforge.net/
OCFS2プロジェクト: https://oss.oracle.com/projects/ocfs2/
ファイルシステム(Linuxファイルシステムに限らない)の詳しい比較については、Wikipediaプロジェクトの「Comparison of file systems」(http://en.wikipedia.org/wiki/Comparison_of_file_systems#Comparison)を参照してください。