私は（おそらく明らかに）比較的新しいLinuxユーザーなので、「なぜこれをしないのですか」というコメントを用意しました。彼らの声を聞きたいのですが…。本物根本的に理解したいなぜこれは現時点では機能しません。
詳細：
- CentOS 7+を実行しています。
- blockdev構成（データベースサーバー用）で先読み値を変更しようとしています。
- コマンドラインで変更を実装できますが、再起動後は維持できません。
- うん、私は持つ再起動。たくさん。
- 変更を維持するためにrc.localファイルを修正しました。
rc.local ファイルの実装は次のとおりです。
#!/bin/bash touch /var/lock/subsys/local /sbin/blockdev --setra 128 /dev/sda /sbin/blockdev --setra 128 /dev/dm-1 /sbin/blockdev --setra 128 /dev/dm-0
ベストアンサー1
忘れてrc.local...
CentOS 7を使用しています。あなたは体系化しました。 /etc/rc.localこれは、以前のメカニズムの下位互換性メカニズムであるため、systemdの二重下位互換性メカニズムです。それ自体システム5の互換性メカニズムrc。以下のハイパーリンクで接続されたAskUbuntuの質問の混乱が示すように、/etc/rc.local使用中に状況が深刻に間違っている可能性があります。したがって、適切なシステムサービスユニットを作成してください。
まずテンプレートサービスユニット。たとえば、次のように呼び出します。/etc/systemd/system/[email protected]
[単位] ドキュメント=https://unix.stackexchange.com/questions/247436/ Description=ストレージデバイス %I のカスタム先読み設定 BindsTo=dev-%i.device [提供する] 種類=使い捨て ExecStart=/sbin/blockdev --setra 128 /dev/%I
適切なデバイスが到着したら、プラグアンドプレイデバイスマネージャ（udev）を予約してサービスデバイスを起動します。特定の要件に合わせてルールを調整する必要があります。
SUBSYSTEM== "ブロック", ACTION== "追加|変更", KERNEL== "sd[az]", ENV{SYSTEMD_WANTS}="custom-readahead@%k"
このSYSTEMD_WANTS設定により、udevは指定されたサービスを開始します。インスタンス化デバイス固有のテンプレート%k。その後、サービスが実行されますblockdev。
明らかにこれを行うもう1つの方法があります。これは、これらの設定を直接設定するudevの機能に依存します。これには、システム化されたテンプレート単位やインスタンス化されたサービスは必要ありません。代わりに、ルールからudevに直接指示してください。
サブシステム == "ブロック", ジョブ == "追加|変更", カーネル == "sd[az]", ATTR{bdi/read_ahead_kb}="128"
===.
どちらにしても、どこでも扱われませんrc.local。