- ZFS の入手先を教えてください
-
ZFS は次の各リリースに同梱されています。
- <ここに OS 名を挿入> では、いつから ZFS が使用できるようになりますか
- ZFS を FreeBSD および Linux (FUSE を使用) に移植するプロジェクトが進行中です。CDDL については、「ライセンスの FAQ」を参照してください。
- ZFS とは何の略語ですか
-
もともと、ZFS とは 'Zettabyte File System' の頭文字を使った略語でした。Sun が気に入った SI 接頭辞のうちで最長のものが 'zetta' ('yotta' は問題外) でした。ZFS は、128 ビットのファイルシステムのため、25 京 6 千兆 Z バイト (Zettabyte。1 Z バイトは 270 バイト) までを格納できるという事実を表しています。やがて、ZFS は 128 ビットの演算能力以外にも多数の機能を備えるようになりました。たとえば、データの完全性の堅牢さ、管理の容易さ、および単純化されたデータ管理モデルなどがあります。
- なぜ ZFS には 128 ビットの演算能力があるのですか
- ディスクの書式はなかなか変更しがたいという事実も手伝って、ファイルシステムは通常のソフトウェアよりも長い寿命を持つことが立証されています。UFS がほぼ現在の形式で約 20 年も使用され続けてきたという事実に鑑みれば、ZFS が少なくとも向こう 30 年にわたって使用され続けると期待するのは非合理的なことではありません。現在、ムーアの法則がストレージにも該当し始め、Sun では 64 ビットを超えるデータを単一のファイルシステムに格納するようになると予測し始めています。このトピック、および 128 ビットで十分な理由については、「Jeff のブログエントリ」を参照してください。
- ZFS にはなにか制限がありますか
-
ZFS の制限は非常に遠大なものにデザインされているため、実際の操作で遭遇することはないでしょう。ZFS は各ストレージプール、ファイルシステム、ファイル、またはファイル属性に 16 Exabyte まで格納できます。ZFS には数十億の名前を格納できます。すなわち、単一ディレクトリ内の各ファイルやディレクトリ、単一ファイルシステム内の各ファイルシステム、ファイルシステムの各スナップショットなどの名前を格納できます。ZFS には数兆の項目を格納できます。すなわち、単一ファイルシステム内の各ファイル、ファイルシステム、ボリューム、プール内の各スナップショットなどを格納できます。
- なぜ ZFS には fsck(1M) のようなユーティリティーがないのですか
-
fsck(1M) のようなユーティリティーを持つことの根本的理由には 2 つがあります。
ファイルシステムの整合性の確認 - 管理者は、ディスク上のファイルシステムが破損することだけは避けたいとしばしば思うものです。そのためには、ほとんどのファイルシステムの場合、オフライン時に fsck(1M) を実行する必要があります。これは時間がかかり高コストです。これに代わるものとして、ZFS ではシステムが稼働中にプール内のすべてのデータを消し込むことができ、その処理中に不良データを検索して修復します。将来はこれを拡張して、バックグラウンドでの消し込みを行ったり、どのファイルに修復不能なエラーが含まれていたかを正確に追跡したりできるようにする予定です。
オンディスク状態の修復 - マシンがクラッシュすると、一部のファイルシステムのオンディスク状態で矛盾が発生します。ジャーナル機能が追加されたことでこれらの問題のいくつかが解決されましたが、ログをロールフォワードできないためにファイルシステムの修復が依然として必要になる場合があります。この場合、確実に修復できるエラー (たとえばリンク元を更新する前にディレクトリエントリを作成するなど) についてのよく知られた病理学があります。ZFS では、ディスク上のデータには常に一貫性があるため、この問題は発生しません。
問題のあるハードウェアやソフトウェアでは、さらに油断のならない問題が発生します。ブロックごとのチェックサムを持つファイルシステムかボリュームマネージャさえ、これ以外のさまざまな病理に弱いため、データは有効だが破損しているという問題が発生します。この場合、障害の形態は完全にランダムで、特にメタデータの場合は、ほとんどのファイルシステムがパニック状態になるかまたは不良なデータをそのままアプリケーションに返します。どちらの場合にも、fsck(1) ユーティリティーはほとんど役に立ちません。このような破損の病理はまだ不明のため、修復できない可能性があります。ZFS では、これらのエラーは冗長構成では統計上存在していません。非冗長構成では、これらのエラーは正しく検出されるものの、ブロックを読み取ろうとすると I/O エラーになります。このような破損を修復するツールは、理論的には作成可能ですが、そのエラー専用のツールになる公算が大きいです。もちろん、ZFS も同様にソフトウェアのバグには影響を受けますが、一般的なツールで修復できるバグの破損のパターンは一貫性である必要があります。5年のZFS開発の間、そのようなパターンは見られていません。
- なぜ du(1) は ZFS と UFS とで異なるファイルサイズを報告してくるのですか
- UFS では、du(1) はファイル内のデータブロックのサイズを報告します。ZFS では、du(1) はディスクに格納されているファイルの実際のサイズを報告します。このサイズにはメタデータや圧縮データも含まれています。この情報は、「このファイルを削除したらどれだけ多くのスペースが空くのか」という質問への本当の答えになります。圧縮機能がオフの場合でも、ZFS と UFS では異なる結果が表示されます。
- 起動のたびに ZFS がパニック状態になったらどうすればよいですか
-
ZFS は、ミラー化や RAID-Z など冗長性の使用により、どのようなハードウェア障害が発生しても破損しないようにデザインされています。残念ながら、レプリケートされていない構成では、一部の障害が発生した場合に、ZFS はプールを読み込む際にパニック状態になることがあります。これはバグで、近い将来に修正される予定です。その際、バックグラウンドでの消し込みや、破損したファイルのリスト表示機能など、その他いくつかのすばらしい機能も登場する予定です。それまでの間、プールが破損したために起動できなくなった場合は、次を実行してください。
- boot using '-m milestone=none'
- # mount -o remount /
- # rm /etc/zfs/zpool.cache
- # reboot
これにより、プールのすべてのデータがシステムから削除されます。プールを作成し直し、バックアップから復元してください。
- ZFS ではホットスペアはサポートされていますか
-
はい、ZFS ホットスペア機能は Solaris Express コミュニティーリリース、ビルド 42、Solaris Express 2006 年 7月リリース、および Solaris 10 11/06 リリースで使用可能です。ホットスペアについては、『 ZFS Administration Guide』を参照してください。
- ZFS プールからデバイスを削除できますか
-
ZFS では、'zpool detach' を使用してミラーからデバイスを削除できます。RAID-Z グループ全体や未ミラー化ディスクなど、最上位の vdev を削除することは現時点ではできていません。この機能は将来のリリース用に計画されています。
- ZFS はルートファイルシステムとして使用できますか
-
ZFS ファイルシステムは現時点ではルートファイルシステムとして使用できませんが、サポートがまもなく始まります。ZFS Boot プロジェクトでは、ZFS ファイルシステムにブートおよびインストールのサポートを提供することに取り組んできました。ZFS Boot リリースのスケジュールから目を離さないようにしてください。
- ZFS はクラスタ環境でサポートされていますか
-
SunCluster 3.2 では、Solaris 10 11/06 リリースに対して可用性の高い (HA)のローカル ZFS ファイルシステムがサポートされます。このサポートでは、システム間でプールを自動的にインポートすることによる、システム間での本稼働中のフェイルオーバーが可能です。
SunCluster 3.2 を使用して可用性の高いローカル ZFS ファイルシステムを構成する場合は、次の注意事項に留意してください。
ZFS ストレージプールに定足数デバイスを追加しないでください。構成済みの定足数デバイスをストレージプールに追加すると、ディスクが再ラベルされて定足数構成情報が失われます。つまり、ディスクがクラスタに定足数投票を提供しなくなるということです。ディスクを定足数デバイスとして構成できるのは、ストレージプールにディスクを追加したあとです。あるいは、ディスクを構成解除し、ストレージプールに追加したあとで、定足数デバイスとして再構成することはできます。
SunCluster 3.2 を Nevada リリースの HA-ZFS とともに使用することはお勧めできません。
ZFS はネイティブクラスタ、分散型、並列ファイルシステムのいずれでもないため、複数の異なるホストからの並行アクセスは提供できません。ZFS は分散型 NFS 環境で共有するときに高い機能を発揮します。
長期的には、Sun では同時アクセスを可能にするために ZFS をネイティブクラスタファイルシステムとして研究していく計画です。この作業の具体的スケジュールは未定です。
- ZFS をサポートしている他社製のバックアップ製品はありますか
-
- EMC Networker 7.3.2. は ZFS ACL を含む ZFS ファイルシステムをバックアップおよび復元します。
- Veritas Netbackup は 2007 年の後半にリリースされる予定のバージョン 6.5 で Netbackup をサポートする予定です。Netbackup の既存のバージョンは ZFS ファイルシステムをバックアップおよび復元できますが、ZFS ACL を保持することができません。
- IBM Tivoli Storage Manager は CLI ツールを使用して ZFS をバックアップおよび復元しますが、GUI では ZFS ファイルシステムが対象として含まれていません。Netbackup 製品と同様に、非簡易な ZFS ACL が保持されません。
- Computer Associates の BrightStor ARCserve 製品は ZFS ファイルシステムをバックアップおよび復元しますが、ZFS ACL が保持されません。
- ZFS は SAN 接続デバイスで動作しますか
-
はい、ZFS は直接接続したデバイスおよび SAN に接続したデバイスで使用できます。しかし、ストレージプールにミラーデバイスまたは RAID-Z の最上位デバイスが含まれていない場合は、ZFS はチェックサムエラーを報告できるだけで、修正まではできません。ストレージプールに SAN 接続デバイス内のストレージを使用して構築したミラーデバイスまたは RAID-Z デバイスが含まれている場合は、ZFS はチェックサムエラーを報告して修正できます。
たとえば、内部的にミラー化されたディスクに基づく SAN ファブリックに LUN を提供するように設定された、SAN 接続ハードウェア RAID アレイについて考えてみます。このアレイから単一の LUN を使用してシングルディスクプールを構築した場合、プールには、ZFS が検出されたエラーの修正に必要とする複製データは含まれません。この場合、ZFS はアレイによって発生したエラーを修正できません。
このアレイから 2 つの LUN を使用してストレージプールを構築したり、3 つの LUN を使用して RAID-Z ストレージプールを作成したりする場合は、ZFS には、検出されたエラーの修正に使用可能な複製データが含まれます。この場合、ZFS はアレイによって発生したエラーの大部分を修正することができます。
ZFS ストレージプールにミラーデバイスや RAID-Z 最上位仮想デバイスがない場合には常に、プールの存続可能性は背後のストレージデバイスの信頼性に全的に依存します。
ZFS ストレージプールに SAN 接続ストレージか直接接続ストレージかを問わず単一のデバイスしか含まれない場合は、RAID-Z、動的ストライプ化、I/O 負荷分散などの機能を利用することはできません。
知らないうちに破損したデータは必ず ZFS で検出されます。一部のストレージアレイでは、チェックサムエラーを検出できても、次の種類のエラーを検出できない場合があります。
- 予期しない上書きや疑似書き込み
- 宛先を誤った読み取りや書き込み
- データパスエラー
ZFS は SAN 接続デバイスとは全般的にはデザインどおりに動作しますが、SAN 接続デバイスよりシンプルなデバイスで ZFS を使用する場合は、使用可能なすべての機能をよりよく活用できます。
つまり、SAN 接続デバイスで ZFS を使用する場合に ZFS の自己修復機能を利用するには、ZFS ストレージプールで冗長性を構成する必要があります。
これは、冗長性がより低いハードウェアレベルで使用可能な場合でもそうです。
- なぜ ZFS にはユーザーやグループの割り当て制限がないのですか
-
ZFS ファイルシステムは、使用状態の表示、プロパティーの管理、バックアップの実行、スナップショットの取得などを行うことができる、管理上の論理的な制御点として使用できます。ZFS モデルは、ホームディレクトリサーバーではユーザーごとに 1 つのファイルシステムを簡単に作成することができます。ファイルシステムは管理上の制御点のため、ZFS の割り当て制限が特定のユーザーに割り当てられていないのは意図的なものです。
ZFS 割り当て制限はユーザー、プロジェクト、グループなどを表すファイルシステムに対して設定することも、ファイルシステム階層の構成要素の全体に対して設定することもできます。このため、複数の割り当て制限を、従来のユーザー別割り当て制限ではできなかった方法で組み合わせることができます。ユーザー別割り当て制限が導入された理由は、複数のユーザーが同じファイルシステムを共有する必要があったためです。
ZFS ファイルシステムの割り当て制限は柔軟性があり、簡単に設定できます。割り当て制限は、ファイルシステムの作成時に適用されます。たとえば、次のように指定します。
# zfs create -o quota=20g tank/home/users
このファイルシステムに作成されるユーザーファイルシステムは、親のファイルシステムに設定されている 20G バイトの割り当て制限を自動的に継承します。たとえば、次のように指定します。
# zfs create tank/home/users/user1
# zfs create tank/home/users/user2
# zfs list -r tank/home/users
NAME USED AVAIL REFER MOUNTPOINT
tank/home/users 76.5K 20.0G 27.5K /tank/home/users
tank/home/users/user1 24.5K 20.0G 24.5K /tank/home/users/user1
tank/home/users/user2 24.5K 20.0G 24.5K /tank/home/users/user2
ZFS の割り当て制限は、ZFS ストレージプール内のディスク容量が追加されたときに、停止時間もなくファイルシステムの動作中に増加させることができます。
ZFS チームでは、制御点としてのファイルシステムをベースとした管理モデルにユーザー別割り当て制限を適合させようとするのでなく、複数のファイルシステム管理を改善しようと努力しています。
メール用のディスク容量を含むユーザー別割り当て制限の代替手段は、Sun Java System Messaging Server など、割り当て制限機能を持つメールサーバーソフトウェアを使用することです。このソフトウェアには、ユーザーメール割り当て制限、割り当て制限警告メッセージ、満了および削除機能が用意されています。
Print-friendly Version
