私にとって、カーネルの I/O スケジューラに最適な選択肢が何かを判断するのは困難でした。まず、それが主観的なものであり、使用するファイルシステムによって異なることがわかりました。
No-op確かに、ソリッド ステート ドライブ (SSD) を使用する必要があることはわかっています。
私が知りたいのは、Ext4 および NTFS ファイルシステム (MBR スタイル) を含む通常の (回転式) HDD に最適な選択肢です。
GPT または MBR は選択に何らかの影響を与えますか?
答え1
確かに、ソリッド ステート ドライブ (SSD) には No-op を使用する必要があります。
必ずしもそうではありません。なぜ SSD を他のスケジューラの利点を必要としない特別なケースとして扱い続けるのかわかりません。ディスクが回転するということは、リクエストをマージすることがより重要になることを意味します。リクエストのマージは、スケジューラが行うことの 1 つにすぎません。
CFQ、Deadline などは、それ以上のことを行います。たとえば、CFQ を使用すると、特定のプロセスに他のプロセスよりも優先順位を付けることができます ( 経由ionice)。一方、Deadline はレイテンシを保証します。どちらも SSD に関連しています。
回転ディスクをなくすということは、単にリクエストをマージするのではなく、ディスクとの間の帯域幅をどのように分割するかについてスケジューラの決定が重要になることを意味します。
編集：また、私のシステムでは、チューナブルを使用してマージをオフにできることも指摘しておきます (スケジューラに関係なく) /sys/block/sdXX/queue/nomerges。Deadline には、フロント マージを無効にするためのチューナブルも用意されています。
私が知りたいのは、ext4 および NTFS ファイル システム (MBR スタイル) を含む通常の (回転式) HDD に最適な選択肢です。
スケジューラの選択は、使用しているファイルシステムにそれほど依存しないと思われます。 dentry と頻繁に使用されるファイルは、いずれにせよファイルシステム キャッシュに保存されます。 いずれにせよ、どのスケジューラにも、あるファイルシステム (XFS、ext3、ext4+extents、reiserfs など) が他のファイルシステムよりも有利になるような機能は備わっていないようです。
NTFS は断片化が激しい傾向があるため、サイズを小さくするとread_ahead_kb効果的です (自分に合ったサイズを見つけるには、いろいろ試してみる必要があります)。基本的に、断片化が激しいボリュームの場合、隣接するデータを取り込むと、正当な要求に使用できるはずの帯域幅が圧迫される可能性があります。
GPT/MBR はこの決定にまったく影響しません。