パーティショニングを販売する

特にUnixy OS（/ usr、/ varなど）でドライブをパーティション分割することに情熱があるのはなぜかとよく疑問に思います。これは、Windowsインストールの一般的なテーマではないようです。

パーティション化により、1つのパーティションがいっぱいになる可能性が非常に高くなり、他のパーティションにはかなりの空き領域ができます。慎重に設計と計画を立てることでこれを防ぐことができますが、状況は変わる可能性があります。私はこれを何度もマシンで経験しましたが、ほとんどは他の人がセットアップしたマシン、または問題のOSのデフォルトのインストール設定です。

私が聞いたもう一つの議論は、バックアップが簡単になるということです。バックアップをどのように簡素化しますか？また、信頼性が向上すると聞きました。繰り返しますが、どのように？

ディスクストレージで発生した問題のほぼ100％は、ディスクの物理的な障害です。同じディスク上のあるパーティションから別のパーティションにデータを移動またはコピーする際にディスクがスラッシングするため、パーティション化はハードウェア障害を加速する可能性があると主張できますか？

私はボートをあまり揺り動かそうとはしていません。私は昔からの管理慣行の正当性を見たいです。

• より高速なfsck。何らかの理由でシステムに障害が発生し、再起動するときにfsckを実行する必要があるとしましょう。fsckが永久に使用できる本当に大きなパーティションでは、システム全体のfsckが完了するまでシステム上で何も機能しません。ルートパーティションが非常に小さくなるようにシステムをパーティションに分割すると、大容量のfsckが完了するのを待つ間にシステムを起動し、いくつかの基本サービスを実行できる場合があります。
  • システムに小さなドライブがある場合、またはシステム上にサービスが1つしかない場合、これは実際には重要ではありません。
  • ジャーナル化されたファイルシステムでは、これはほとんどの場合重要ではないかもしれませんが、ジャーナル化されたファイルシステムでも、完全なfsckを実行する必要がある場合があります。
• fsを読み取り専用でマウントできるため、セキュリティが向上しました。
  • たとえば、通常の使用中に/ usrに書き込む必要はありません。それでは、なぜファイルシステムを単にマウントして読み取り専用にするのではありません。書き込みが不要なファイルシステムを読み取り専用にすることで、スクリプトキディ攻撃を防ぐことができます。また、意図しないときに物を破壊することを防ぐことができます。
  • 更新を適用する必要がある場合は、システムを読み取り/書き込みとして再マウントする必要があるため、これによりシステムのメンテナンスが難しくなる場合があります。
• 改善されたパフォーマンス、特定のサービス/用途の機能。
  • 一部のファイルシステムは、特定のサービス/アプリケーションにより適しています。または、場合によっては、より適切に動作するようにファイルシステムを構成できます。たぶん、あなたはたくさんの小さなファイルを持つファイルシステムを持っていて、より多くのinodeが必要です。または、いくつかの大きなファイル、仮想ディスクイメージを保存する必要があるかもしれません。

多くのパーティションを設定することは、すべてのシステムで行うべきことではないと思います。個人的には、ほとんどのLinuxサーバーでは、1つの大きなパーティションをセットアップするだけです。私のシステムのほとんどは小さなドライブを持ち、単一の目的であり、インフラストラクチャの役割（dns、dhcp、ファイアウォール、ルーターなど）に対応しているためです。ファイルサーバーで、システムからデータを分離するためのパーティションを設定します。

同じディスク上のあるパーティションから別のパーティションにデータを移動またはコピーする際にディスクがスラッシングするため、パーティション化はハードウェア障害を加速する可能性があると主張できますか？

うまく分割されたシステムでは、故障の可能性が高まる可能性が非常に高いと思います。

/ home /を分離する理由の1つは、オペレーティングシステムを再インストールでき、ユーザーデータが失われる心配がないことです。さらに、すべてを読み取り専用またはnoexecのいずれかでマウントするには、多くのセキュリティが必要です。ユーザーがコードを記述できる場所でコードを実行できない場合、攻撃経路は1つ少なくなります。

ただし、あるパーティションのディスク領域が不足しているのに別のパーティションにディスク領域が存在することのマイナス面は深刻な迷惑であるため、私はパブリックマシンでそれを気にするだけです。これを回避する方法として、ソフトウェアRAIDやZFSを使用してパーティションを簡単に動的にサイズ変更できるようにする方法がありますが、私はそれらの経験がありません。

• バックアップの簡素化

不要なものではなく、必要なものの（dumpfsなどを介して）バックアップを作成できます。dump（1）は、tar（1）よりも優れたバックアップシステムです。

• パーティションを埋める

それもパーティション化の議論です。ユーザーがhomedirをいっぱいにしても、サーバーが壊れたり、Webサーバーがダウンしたり、ログが発生したり、rootがログインしたりすることはありません。

また、データのセクション（/ homeなど）を別のディスクにさらに透過的に移動できます。コピーしてマウントします。シャドウコピー/スナップショット/などを許可するものを使用している場合は、ライブでも実行できます。

/ varを別のパーティションに保持するように常に教えられているので、制御不能なログファイルを取得した場合は、ドライブ全体ではなく単一のパーティションを詰まらせることになります。システムの他の部分と同じスペースにあり、ディスク全体を100％満たすと、クラッシュして、厄介な復元が行われる可能性があります。

Zoredacheが提唱するすべての議論は有効です。少し詳細をいじることができます（最初に存在するシステムの理由が他のファイルシステム上にある場合、他のファイルシステムをfsckしても他のことができるようにマシンを高速化することはあまり役に立ちません） ; しかし、それらはすべて、ちょっとした事後正当化です。

本当に昔の時代には、別々のパーティションにファイルシステムがありませんでした。ディスクが本当に小さかったので、別々のディスクに持っていました。10MBと考えてください。（1）これで、小さな/パーティション、/ varディスク、/ usrディスク、/ tmpディスク、および/ homeディスクができました。さらにスペースが必要な場合は、別のディスクを購入しました。

その後、「大きな」50MBディスクはmoonプログラムよりも低コストになり、突然、システム全体を使用可能なユーザースペースのある1つのディスクに配置することが可能になりました。

それでも、コンピューターが生成できるサイズに比べてディスクサイズが小さいので、/ varと/ optおよび/ homeを分離して、いっぱいになってもコンピューターがダウンしないようにすることをお勧めします。

今日、企業の状況では、OSを分割しません。特にユーザー生成データの場合、データは分割されます。しかし、それはある種の高速および/または冗長ディスクアレイ上にあるためです。ただし、/ varと/ usrはすべて、/と同じパーティションに存在します。

ホーム環境でも同じことです。/homeは、おそらく別のディスク/アレイ上にある必要があります。これにより、OSフレーバーが必要なものをインストール/アップグレード/ブレーク/修正することができます。

これは、/ varや/ usrなどのツリーがどれほど大きく推測されても、陽気に間違っているか、途方もなくオーバーコミットするためです。私の昔の（学校の）同僚の1人はパーティション分割を誓っています。彼が私が作成した180日間のfsckを最後までやり通すと、彼からいつも悲しみを覚えます。しかし、私は自分のキャリア全体で何かがいっぱいになった/システムをダウンさせた回数を数えることができますが、今年はこれまで誰かのシステムを見つめてきた回数を数えることができます/ varが（たとえば）1GBを超える必要は決してなく、間違っていたため、システム上の他の場所にある/ varと '00sの空きGBをじっと見つめることにしました。彼らは私に良いことをします。

今日の大きなディスクの世界では、OSツリーを分割する本当の理由があるとは思いません。ユーザーデータ、はい。しかし、/ varと/ usrと/ var / spoolなどのパーティションは別々ですか？番号。

（1）=そして、そのサイズを選択するだけで、10MBと言っているコメントを誰かに取得できますか？贅沢。ディスクが単に...

返信：

パーティション化により、1つのパーティションがいっぱいになる可能性が非常に高くなり、他のパーティションにはかなりの空き領域ができます。

Linuxマシンでは、これを防ぐためにLVM（論理ボリューム管理）が使用されます。ほとんどのファイルシステムでは、サイズ変更が可能です（オンラインでも可能です）。用途ごとに異なるパーティションを作成し、それらを異なるファイルシステムにフォーマットします（つまり、すぐに削除できる大きなダウンロードファイル用のxfs）。もっとスペースが必要ですか？新しいドライブをマウントし、データをそこに移動してから、データがあった場所にマウントします。ユーザーとアプリケーションに対して完全にシームレスです。

LVMを使用すると、ディスクまたはパーティションをボリュームグループに追加し、そのグループに論理ボリュームを作成できます。ボリュームグループに空き領域を残すと、いっぱいになるパーティションを増やすことができます。ファイルシステムがサポートしている場合（ext3、ext4、reiserfs）、割り当て過ぎたパーティションを縮小できます。

たとえば、/ dev / sda1にブートパーティションを作成し、2番目の（フォーマットされていない）パーティションを/ dev / sda2に作成します。

pvcreate /dev/sda2 # add the partition to LVM
vgcreate vg /dev/sda2 # create a volume group with sda2 in it
lvcreate -n root -L5G vg
lvcreate -n home -L10G vg
lvcreate -n downloads -L100G vg

mkfs.ext3 /dev/vg/root
mkfs.ext4 /dev/vg/home
mkfs.xfs /dev/vg/downloads

mount /dev/vg/root /
mount /dev/vg/home /home
mount /dev/vg/downloads /downloads

/ downloadsにより多くのスペースが必要な場合（ファイルシステムのマウント中）：

lvresize -L+50G /dev/vg/downloads
xfs_growfs /dev/vg/downloads

これで、150GBのダウンロードパーティションができました。家でも似ています。実際、今日はext4 lvmの「パーティション」のサイズを変更しました。一方で、論理ボリュームは実際にはパーティションではなく、パーティションのサイズが間違っていると言うことは、私の個人的な経験から言えます（価値がある以上のトラブル）。

従来のUnixのパーティション分割スキームは、間違いなく旧来の方法であり、以前ほど有用ではありません。Unixシステムの稼働時間を数年で測定し、シェルをいじくり回している何十何百というユーザーがいた頃、読み取り専用として/ usrをマウントすることはシステムを保護する便利な方法でした。現在、パッチを適用するためにファイルシステムを再マウントすることは、より労働集約的であり、それほど有用ではありません。

昔の私の大学では、Unixクラスターには標準のunixツールを備えた読み取り専用ファイルシステムがあり、アドオンアプリケーションは/ usr / localにありました。これはNFSおよび後でAFSファイルシステムでした。その一部は利便性でした...高速の4Mbまたは10Mbネットワークでアプリを実行できるときに、クラスター内の12個のボックスでソフトウェアを再コンパイルしたかったのは誰ですか？今日、適切なパッケージマネージャーと大量の安価なディスクが存在するため、それほど大きな問題ではありません。

私は、Veritas Volume Managerを搭載したSunのボックスで1999年頃にプロセスが変わり始めたと思います。これにより、ディスクを移動する際の痛みのしきい値が大幅に減少しました。

今日、パーティション分割を考えるとき、データ保護とパフォーマンスの観点から考えています。実例：

• ティア1 SANは非常に高速で、非常に可用性が高く（5 9）、複製され、非常に高価です。ミッションクリティカルなデータベースまたはトランザクションログがそこに存在します。
• ティア2 SANは高速で、利用可能（4 9's）で高価です。アプリケーションまたは優先順位の低いデータがここに存在します。
• ティア3 SANが利用可能（4 9's）、安価です。パフォーマンスに敏感でないものはそこに住んでいます。

これらの考慮事項はWindowsにも適用されます。約4万のクライアントを管理するSCCMサーバーがあります。データベースとログはメガバックIBM DS8000ディスク上にあります。ソフトウェアパッケージは、GBあたり60％安くなった大型の低速SATAディスクを備えたEMC Celerraにあります。

この質問はOS固有のものではないことを理解していますか？

Windowsでは、すべてのマシンにできる限り少ないパーティションを割り当てる傾向がありますが、システムとデータの2つ以上です。マシンに2つの物理ディスクがある場合、1つ（より小さい）はSYSTEM、もう1つはDATAです。ディスクが1つしかない場合は、2つのパーティションに分割します。

その理由は1つだけです-マシンを再インストールする必要があるとき（そしてそのような時間があります）、SYSTEMパーティションの内容を心配する必要はありません-それで完全なフォーマットを行い、クリーンインストール。もちろんこれは、私のドキュメント（およびできればデスクトップも）をDATA上のフォルダーにマップする必要があることを意味しますが、それは特にVista以降で簡単に実行できます。

また、より多くのパーティトン（ゲーム、音楽、映画など）を作成しようとしましたが、その結果、それらの一部が他のものにあふれてしまい、注文よりも混乱が生じました。

（、単一の大きなディスクが利用可能であると仮定すると）私が入れhomeやvar問題、そして感動家なしで簡単にOSのアップグレードを可能にしますが、去る|別々のパーティションに制御する「すべてのスペースを埋める制御のうち、[ログファイルをユーザー]を」一緒に休みます。

古いハードウェアではboot、カーネルイメージにブートローダーがアクセスできるように、別のパーティションを用意する必要がある場合がありました。

特定のパーティションがいっぱいにならないようにすることができるので、一方のディスクがいっぱいになり、もう一方のディスクに空きスペースがあることを言及します。これがパーティション分割の理由の1つです。以前はクォータが管理されていた方法でしたが、他のパーティションですべてのユーザーに0のクォータを割り当てて、ディレクトリを見つけることができた場合にファイルを隠し始めないようにする必要がありますに書き込むことができます。

バックアップの簡素化については、各パーティションの最大サイズがわかれば、単一のテープにきちんと収まるサイズであり、一定の時間で完了することができることを確認できます。

信頼性に関しては、私が考えることができる唯一のことは監視です-あるパーティションが必要以上に成長していることをより簡単に確認でき、それを調べる理由を教えてくれます。

...さて、これらすべてが言われているように、私たちは各ユーザーが共有マシン上で20MBの小さなクォータを与えられる日々にはほど遠い状態です。古い習慣のいくつかは意味がありませんが、プロセスが狂って/ varを満たし、次に/を満たし、物事が停止するとき、生産マシンで持っていることはそれほど悪いことではありません。

自宅にはパーティションがありますが、インストールされたOSの管理を簡単にするためだけです。

個人的には、子供のコンピューターでのみパーティション分割を使用します。OSに大きなパーティションを作成し、OSパーティションのイメージに小さなパーティションを作成して、マシンが使用不能になったときに、イメージからすばやく復元できるようにします。

エンタープライズ環境では、パーティション分割について説得力のある議論を聞いたことはありません。

適度なものはすべて良いことです。障害が発生したときに、ディスクの満杯やファイルシステムの破損などの問題を特定するための優れたツールになります。

ハードウェア障害と混同しないでください-これらはハードウェア冗長性（RAID）で処理する必要があります

そうは言っても、最近のファイルシステムの障害はそれほど頻繁に発生しません。一部のユーザーは、オンライン整合性チェック（ZFSなど）も行います。オフラインfsckがある時点でなくなることを願っています...

一方、これをやりすぎると、最後に（あなたとあなたのチームにとって）より多くの作業が必要になります。