スワップパーティションをSSDではなくHDDに置く必要があると読みました。
私の質問は次のとおりです。
静的に構成されたスワップスペース(ほとんどすべてのディストリビューションが使用するタイプ)は、ファイルシステムと同じように/etc/fstab
で構成されます。
一般的なエントリは次のようになります。
UUID=21618415-7989-46aa-8e49-881efa488132 none swap sw 0 0
また、フラグフィールド(4番目のフィールド)でdiscard
またはnofail
が指定されていることも確認できます。そのようなすべての行は1つのスワップ領域に対応します(パーティションになるhaveではありません。スワップファイル、またはスワップディスク全体を使用できます)。
実際に特定のケースでは、代わりに動的に構成されたスワップ領域がある場合がありますが、メモリ管理に関連する問題のある動作を引き起こす可能性があるため、これはかなりまれです。この場合、構成は、実行時に必要に応じてスワップファイルを作成して有効にするユーザースペースコンポーネントによって完全に処理されます。
いくつ必要かというと、これは答えるのが難しい質問ですが、実行する予定のさまざまなLinuxディストリビューションの数は、あるディストリビューションを別の休止状態で実行できるようにしたい場合(およびそれはあなたのシステムを台無しにする本当に簡単な方法なので、おそらくこれをしたくないでしょう)。
ほとんどすべての主要なディストリビューション(Fedora、OpenSUSE、Linux Mint、Debian、Ubuntuを含む)のインストーラーを実行すると、システム上の既存のスワップパーティションが検出され、それらのディストリビューションの構成に追加されます。インストール(手動パーティションを選択した場合を除く)。ほとんどの場合、これによりシステムが適切に構成されます。
それを除いて、多くのディスクを備えたサーバーシステムについて話していない限り、個人的には複数のスワップパーティションを回避することをお勧めします。 。
fedoraとUbuntuとしましょう。
…どちらも現在はsystemdオペレーティングシステムです。
Systemdはさまざまな種類のユニットを採用しています。 .mount
ユニットファイルは、ボリュームをマウントするように指示します。 .swap
ユニットファイルは、カーネルにスワップパーティションについて通知するように指示します。 (.service
ユニットファイルは、サービスの実行方法を指示します。これらはネイティブのsystemdメカニズムです。それらを制定するために、systemd自体は、関連するシステムコールを行う子プロセスをフォークします。
そのようなsystemdオペレーティングシステムでsystemctl
コマンドを(--all
とともに)使用すると、ロードされた.swap
ユニットについて通知されます。例えば:
dev-disk-by\x2dpartuuid-40549710\x2d05.swap loaded active active /dev/disk/by-partuuid/40549710-05 dev-disk-by\x2duuid-1bb589e8\x2d929f\x2d4041\x2d81f4\x2dff2b339b4e2a .swapロードされたアクティブアクティブ/dev/disk/by-uuid/1bb589e8-929f-4041-81f4-ff2b339b4e2a dev-sda5.swapロードされたアクティブアクティブ/ dev/sda5
また、.mount
ユニットについても説明します。
システム管理者は、xeが.swap
、.service
、およびその他のユニットファイルを手動で書き込むことができるのと同じように、実際にそのような.socket
ユニットファイルを手動で書き込むことができます。 systemd自体は、ファイルシステム内のユニットファイルを探すだけです。それらはそのネイティブなメカニズムです。
Systemdを使用して、これらのユニットファイルの内容とファイルシステムのどこにあるかを示すこともできます。
$ systemctl cat dev-disk-by \\ x2duuid-1bb589e8 \\ x2d929f \\ x2d4041 \\ x2d81f4 \\ x2dff2b339b4e2a.swap #/ run/systemd/generator/dev-disk-by\x2duuid-1bb589e8\x2d929f\x2d4041\x2d81f4\x2dff2b339b4e2a.swap #systemd-fstab-generator [Unit] SourcePath =/etc/fstab [.____により自動生成。] Documentation = man:fstab(5)man:systemd-fstab-generator(8) [Swap] What =/dev/disk/by-uuid/1bb589e8 -929f-4041-81f4-ff2b339b4e2a Options = sw $
手で書くことができます。 通常ただし、このような.mount
および.swap
ユニットファイルはgeneratorsと呼ばれるプログラムによって自動的に生成されます。そのような2つのジェネレータはsystemd-fstab-generator
とsystemd-gpt-auto-generator
です。これらは両方とも、bootstrapプロセスの早い段階でsystemctl daemon-reload
コマンドに応答して実行され、(上記のように)ユニットファイルのロード全体をドキュメント化されていないサブディレクトリに生成します。 /run/systemd/
。systemd自体生成されたユニットファイルを使用する。
前者のジェネレーターは/etc/fstab
を読み取り、そのファイル形式に対するいくつかのsystemd拡張を認識します。回答コメントで指摘したように、従来のスワップパーティションにはmount typeのsw
があり、他のオペレーティングシステムがこのテーブルのスワップレコードを認識することがわかります。しかし、Linuxソフトウェアは、代わりにVFS typeを認識する代わりの方法を取り、swap
をVFSタイプとして探します。 systemd-fstab-generator
も例外ではなく、ネイティブメカニズムに変換するときに/etc/fstab
が解釈されます。
後者のジェネレーターは、EFIシステムパーティションを保持する同じディスク上にあるEFIパーティションテーブルを処理し、さまざまな既知のパーティションタイプ GUIDを持つEFIパーティションテーブルエントリを探します。それらのGUIDの1つは、従来のGUID Linuxスワップパーティションに割り当てられたものであり、systemd-gpt-auto-generator
がそのGUID(それが基準を満たすsystemd docoで指定)は、.swap
ユニットを作成しますno /etc/fstab
はまったく関与しません。
もちろん、このプロセスには多くの副作用があります。たとえば、/etc/fstab
にはテーブルへの主キーがないため、レコードに「spec」フィールドと「file」フィールド(つまり、「what」と「where」)が重複している可能性があります。ただし、ネイティブのsystemdメカニズムでは、「file」(つまり「where」)フィールドは、ユニット名に埋め込まれた.mount
ユニットの一意のキーです。 2つの.mount
ユニットで共有することはできません。 .swap
ユニットの場合、「spec」(つまり「what」)フィールドはユニットの一意のキーです。 2つの.swap
ユニットで共有することはできません。したがって、/etc/fstab
のすべてのレコードが必ずしもネイティブメカニズムに変換可能であり、動作するわけではありません。特に、2つの異なる目的で同じマウントポイントをリストしたり、2つの異なる方法で同じスワップパーティションをリストしたりする場合は機能します。
同様に、/etc/fstab
をネイティブメカニズムとsystemdのネイティブメカニズムユニットをアクティブにする他の方法がありますに変換したため、動作はシステム化されていないオペレーティングシステムの動作とわずかに異なります。 .mount
ユニットは、デフォルトでは、マウントされたストレージデバイスの外観に応じて、ブートストラップ後でもsystemd-udevd
によって自動的にアクティブ化されます。または、一部のWants=
またはRequires=
ユニットの.service
または.socket
としてリストすることもできます。つまり、アクティブになると(再)アクティブ化されます。 RequiresMountsFor=
もあります。
従来、オペレーティングシステムのインストーラープログラムと、その後システムを再構成するsystemd管理者は、sw
エントリを/etc/fstab
に書き込みました。そして、それがネイティブの.mount
および.swap
ユニットが最終的に自動生成される方法です。インストール/設定ユーティリティは、そのユーザーインターフェイスでシステム管理者が何らかの選択を行い、一致する/etc/fstab
を書き込むため、スワップファイルが置かれた場所を「認識」します。時々その選択はインストールの一部としてスワップパーティションを作成する必要があります。;時々それはディスクですでに見つけたスワップパーティションを使用するだけです。(パーティションタイプも確認するインストーラー)。
しかし、systemdの人々は、ほとんど空の/etc
ツリー、つまりステートレスシステムから自動構成するオペレーティングシステムというこの考え方を持っています。これが、EFIを読み取るジェネレーターのようなメカニズムです。パーティションテーブルがすべてです。 systemdの人々の計画では、/etc/fstab
はなく、実際に/etc
の下に永続的な構成データはありません。このすべてのものは上のパーティションテーブルの内容から推定されますdisc、すべてのbootstrapおよびすべてのsystemctl daemon-reload
。現在、オペレーティングシステムインストーラープログラムを宣伝しています/etc/fstab
を記述しないでください] _ =。
もちろん、従来のスキームでは、実際に各オペレーティングシステムに独自のプライベートスワップパーティションを持たせ、お互いのスワップパーティションに触れさせないようにすることができます。実際、スワップパーティションを介してディスクにhibernateを使用していて、休止中に別のオペレーティングシステムにマルチブートできることを期待している場合(これは非常に悪いアイデアです。 =ファイルシステムの破損をこのように引き起こすのは非常に簡単です)。
Systemdスキームでは、systemdの人々が想定しているようにオペレーティングシステムがまだ「ステートレス」でなくても、前述のジェネレーターは実行されます。したがって、必要なパーティションタイプを持つallスワップパーティション(ESP /ルートディスク上)は、すべてのsystemdオペレーティングシステムで自動的に採用されます。自動的に検出されたすべてのスワップパーティションを共有するため、インストールされているオペレーティングシステムごとに1つのスワップパーティションを作成する必要はありません。
systemd.swap
。 systemdマニュアルページ。 freedesktop.org。systemd-fstab-generator
。 systemdマニュアルページ。 freedesktop.org。systemd-gpt-auto-generator
。 systemdマニュアルページ。 freedesktop.org。歴史的に、スワップパーティションは/etc/fstab
でタイプswap
のエントリとともに指定されます。起動時に、起動プロセスはそのファイルを読み取り、その構成をカーネルにプッシュします。
/etc/fstab
のエントリの例は次のとおりです。
/dev/sdb none swap sw 0 0
私はsystemd
がスワップを管理する方法に精通していませんが、最終結果は同じだと思います。ユーザースペースプロセスはスワップに割り当てられているスペースを認識しており、ユーザースペースプロセスはカーネルに通知します。
他のすべての回答は、起動時にスワップファイルシステムをポイントする方法について言及しています。
ただし、他の回答に追加するいくつかのポイント:
mkswap
を使用する必要があります。swapon
;を使用します。swapoff
を使用します。