22TBディスクをパーティション分割する方法は？

に22TBのディスクがあり/dev/sdbます。22TBパーティションを作成するにはどうすればよいですか？ファイルシステムについてはあまり気にしないでください- ext4またはzfs大丈夫です。

CentOS 6.2の実行-パーティションはデータダンプとして使用されます。単一のデータストリームのみであるため、現在どのファイルシステムを選択するかは気になりません。ディスクは、12x2TBニアラインSASドライブとDell Percコントローラーで構成されています。

22TBのパーティションが必要です。

最も簡単な解決策は、GPTパーティショニング、Linuxの64ビットバージョン、およびXFSを使用することです。

• GPTが必要なのは、MS-DOSスタイルのMBRパーティションテーブルfdiskが2つのTiBディスクに制限されているためです。そのため、のparted代わりにまたはの代わりに別のGPT対応パーティションプログラムを使用する必要がありますfdisk。（gdisk、gpartedなど）

• 64ビットカーネルが必要なのは、32ビットカーネルでは、要求するよりも小さいファイルシステムに制限されるためです。32ビット整数に基づくサイズ制限に達するか、ファイルシステムを適切にサポートするために十分なRAMをアドレス指定できなくなります。

• XFSは唯一のソリューションではありませんが、私の意見では、RHELシステムにとって最も簡単なソリューションです。

  RHEL 6でこれにext4を使用することはできません。ファイルシステムは1 EiBファイルシステムをサポートするように設計されていますがe2fsprogs、RHEL 6 に含まれるバージョンとその派生バージョンには16 TiBボリュームサイズの人為的な制限があります。Red HatとCentOSの両方は、ドキュメントでこれを呼び出しています。（ext4 16 TiBの制限は、RHEL 7では 50 TiBに大幅に引き上げられました。）

  ZFSはあなたの状況では実用的ではないかもしれません。いくつかの法的および技術的な制限があるため、ZFSだけが提供するものが必要な場合を除き、私は完全に推奨できません。

  選択した2つのファイルシステムを除外したので、XFSをお勧めします。これはRHEL 7のデフォルトのファイルシステムであり、すべてのRHEL 6バージョンでサポートされているファイルシステムとして利用可能であり、RHEL 6がリリースされた後のRHEL 5リリースにバックポートされました。

プロセスは次のとおりです。

1. mkfs.xfs引数なしで実行してインストールしたかどうかを確認します。存在しない場合は、ユーザーランドXFSツールをインストールします。

   # yum install xfsprogs
   

   それが失敗した場合、おそらく、デフォルトパッケージリポジトリにこれがない古いOSを使用しているためです。本当にアップグレードする必要がありますが、それが不可能な場合は、CentOSPlusまたはEPELから入手できます。kmod_xfsパッケージをインストールする必要がある場合もあります。

2. パーティションを作成します。

   22 TiBボリュームがオン/dev/sdbになっていると言うので、コマンドpartedは次のとおりです。

   # parted /dev/sdb mklabel gpt
   # parted -a optimal -- /dev/sdb mkpart primary xfs 1 -1
   

   これにより、単一のパーティションでボリューム全体を引き継ぎます。実際には、ボリュームの最初の1 MiBを無視して、Advanced Format HDDおよびSSDから完全なパフォーマンスを得るために必要な4 KiBのアライメントを実現します。

   この手順をスキップして、XFSでボリューム全体をフォーマットできます。つまり、次/dev/sdbの例ではの代わりに使用します/dev/sdb1。これにより、セクターのアライメントの問題が回避されます。LinuxベースのOSのみが表示するボリュームの場合、話す価値のある欠点はありませんが、リムーバブルボリュームまたはマルチブートコンピューターの内部ボリュームでこれを行うことには注意してください。OS（WindowsやmacOSなど）は、パーティションレスハードドライブが表示されるたびにフォーマットすることを提案します。これを解決するには、ファイルシステムをパーティションに配置します。

3. パーティションをフォーマットします。

   # mkfs.xfs -L somelabel /dev/sdb1
   

4. /etc/fstabエントリを追加します。

   LABEL=somelabel    /some/mount/point    xfs     defaults   0 0
   

5. マウントアップ！

    # mount /some/mount/point
   

あなたがダウンしたい場合はLVMのパスを、上記の手順は、基本的にコマンドの第二セットのちょうどより詳細なバージョンです、ユーザーbsdの以下の答え。上記のコマンドの前に、彼の最初のコマンドセットを実行する必要があります。

LVMは複雑なコストで特定の利点を提供します。たとえば、後で物理ボリュームを追加してLVMボリュームグループを「成長」させ、論理ボリューム（「パーティション」など）を成長させるスペースを確保することで、論理上にあるファイルシステムを成長させることができます。ボリューム。（私が複雑さについて何を意味するか見てください:)）

他の提案の代替として。
ディスクをパーティション分割する必要はまったくありません。1つ以上の論理ボリュームを
使用して、ボリュームグループを簡単に作成できます。

pvcreate /dev/sdb
vgcreate data /dev/sdb
lvcreate --name dump -L '100%VG' data

これで、任意のファイルシステムタイプでフォーマットできる論理ボリュームがで​​きました。

mkfs.XXXX /dev/mapper/data-dump #<- XXXX can be ext4, xfs, btrfs, reiser
mount /dev/mapper/data-dump /mntpt

質問への質問：「22TBディスクをパーティション分割する方法」を尋ねた後、再び質問で、22TBパーティションが必要だと言いました。だから、これは第一に曖昧さです。

22TBのスペースをサポートできる単一のブロックデバイスが既にある場合は、すでに22TBのパーティション全体を所有しています。必要なのは、その上にあるファイルシステムだけです。これにより、システムプロセスによる読み取り/書き込みのためにデバイスをマウントおよび使用できるようになります。さらに、Linuxカーネルを64ビットモードで実行し、22TBのデータ増加をサポートし、拡張できるファイルシステムモジュール/ドライバーを使用する必要があります。簡単に。パフォーマンスはまったく別の側面です。そのような場合、XFS64ビットのファイルシステムであり、100万テラバイトものファイルシステムを処理できるという理由で、ファイルシステムとして選択することを選択します。最大9個のEXABYTESをサポートします。

2^63  = 9 x 1018 = 9 exabytes 

XFSの詳細：http : //oss.sgi.com/projects/xfs/

巨大な22TBブロックデバイスをさらにパーティション分割する場合はgparted、デバイスを使用可能なパーティションに分割し、それらをファイルシステムでフォーマットしてマウント可能にします。

DELL perc RAIDコントローラーを持っていることを述べているので、ハードウェアRAIDコントローラーを持っているようです-つまり、どのRAID構成（正確にはどのRAIDレベルを使用していますか）を教えなければなりません、そしてほとんどの場合、 22TBのスペースを完全に使用することはできませんが、間違っている可能性があります。

ZFSを使用する場合、パーティションを作成する必要はありません。22TBデバイスにZFSプールを作成し、デフォルトのデバイスを使用したくない場合は、その中にファイルシステムを作成します。何らかの理由でzpoolがディスク全体の使用をサポートしていない場合は、最初にEFIラベルと内部で利用可能なスペース全体を使用してパーティションを作成し、次にそのパーティションを使用してプールを作成します。

いくつかの理由から、このような大規模なファイルシステムにはZFS以外の使用をお勧めしません。最も明らかなのは、残忍な電源オフ（例：カーネルパニックまたは電源不足）がある場合、fsckは従来のファイルシステムを回復するのに苦痛な時間がかかる可能性があることです。一方、ZFSはfsckを必要としないため、プールを即座にインポートします。

ハードウェアRAID構成を解除し、12台のデバイスをJBODとして使用して、ソフトウェアRAID機能を利用してZFSプールを構築することをお勧めします。目標がパフォーマンスである場合、ディスクのペアをミラーリングすることがあり、目標が最大化されたスペースである場合、RAIDZ、RAIDZ2、またはRAIDZ3構成を使用できます。これを行うと、データの信頼性とソリューションのフォールトトレランスが大幅に向上します。

標準パーティションテーブルを使用してこれが現在可能かどうかはわかりません。標準パーティションテーブルスキームでは、ボリュームは2 ³²セクターに制限されています。セクターあたり512バイトで、2TB前後のセクターに割り当てるための数字を使い果たすだけです。

ただし、標準のパーティションテーブルの代わりにGUIDパーティションテーブルを使用する場合は、これを実行できる必要があります。GUIDパーティションテーブルにより、ボリュームをzettabyteの範囲に拡張できます。ほとんどのLinuxディストリビューションはGUIDボリュームから起動できますが、現在のバージョンのWindows（EFI上のWindows 7を除く）はありません。

fdiskなどの一部のツールはGUIDボリュームでは機能しませんが、GPartedなどの他のツールは機能します。GUIDパーティションテーブルを作成したら、そのサイズのボリューム（EXT4など）をサポートするいくつかの一般的なファイルシステムのいずれかを使用してボリュームを作成できる必要があります。

他の場所で述べたように、パーティションテーブルでは、最大9.4 ZiBのサイズ（9.4×10 ²¹バイト）のパーティションをサポートするため、GPTは優れたオプションです。

あなたのファイルシステムにとって、Linux BTRFSには優れたコピーオンライトファイルシステムがあります：

1. copy-on-write属性は、重複ファイルが2回保存されないことを意味します。
2. オンザフライ圧縮機能を備えているため、データはLZOまたはGZipを介してディスクに書き込まれ、ディスクから読み取られる前に実行され、物理ディスク容量が節約されます。
3. RAID-1、RAID-10、RAID-5、およびRAID-6構成で、オーバーヘッドなしで冗長性をサポートします。
4. 速度が重要な場合、RAID-0もサポートします。
5. また、サブボリューム、スナップショットなども備えています。
6. ほとんどすべてのファイルシステムのタスクはオンラインで行われるため、通常はファイルシステムをアンマウントして問題を修正する必要はありません。

機能はZFSに似ていますが、メインラインLinuxカーネルの一部です。

冗長性やそれをバックアップする機能を探していない場合は、おそらく次のことができます。

mkfs -t ext4 /dev/sdb