Для меня было проблемой выяснить, какой выбор лучше для планировщика ввода-вывода в ядре. Сначала я узнал, что это субъективно, а затем это зависит от используемой файловой системы.
Я знаю, что вам No-opопределенно следует использовать твердотельные накопители (SSD).
Я хочу узнать, какой выбор лучше всего подходит для обычных (вращающихся) жестких дисков, содержащих файловые системы Ext4 и NTFS (стиль MBR).
И влияет ли GPT или MBR на мой выбор?
решение1
Я знаю, что для твердотельных накопителей или SSD обязательно следует использовать функцию No-op.
Не обязательно. Я не знаю, почему люди продолжают относиться к SSD как к какому-то особому случаю, когда не нужны преимущества других планировщиков. Наличие вращающихся дисков просто означает, что важнее объединять запросы. Объединение запросов — это всего лишь одна из функций планировщика.
CFQ, Deadline и т. д. делают больше. Например, CFQ позволяет вам давать определенным процессам приоритет над другими (через ionice), тогда как Deadline дает вам гарантии задержки. Любой из них может быть актуален для SSD.
Избавление от вращающихся дисков означает, что ваше решение относительно планировщика, скорее всего, будет больше зависеть от того, как вы хотите разделить полосу пропускания на диск и с диска, а не просто от объединения запросов.
РЕДАКТИРОВАТЬ:Я также укажу, что в моей системе слияния можно отключить (независимо от планировщика) с помощью /sys/block/sdXX/queue/nomergesнастройки. Deadline также предоставляет настройку для отключения передних слияний.
Я хочу узнать, какой из них лучше всего подходит для обычных (вращающихся) жестких дисков с файловыми системами ext4 и NTFS (стиль MBR).
Выбор планировщика, вероятно, не сильно зависит от используемой вами файловой системы. Dentry и часто используемые файлы в любом случае попадают в кэш файловой системы. В любом случае, ни один из планировщиков, похоже, не имеет функций, которые могли бы дать преимущество одной файловой системе (XFS, ext3, ext4+extents, reiserfs и т. д.) над другой.
NTFS имеет тенденцию к сильной фрагментации, поэтому меньший размер, read_ahead_kbвероятно, будет выгоден (вам нужно поэкспериментировать, чтобы понять, что подходит именно вам). По сути, если это сильно фрагментированный том, то извлечение соседних данных, вероятно, просто задушит полосу пропускания, которая могла бы быть выделена законному запросу.
И GPT/MBR вообще не влияют на это решение.