Предпочтительный планировщик ввода/вывода вашей GNU/Linux?

cat /sys/block/sda/queue/scheduler
noop [deadline] cfq

У всех так
Но Smartassv2 (gov) и SIO (sched) рулят

Во влажных мечтах?

cfq

Подумай вот о чем: при каждом монтировании/отмонтировании пишется (в одно и то же место!) некая информация об этом великом событии.

Ты уверен что в одно и то же? А как же контроллер, которому лучше знать, куда писать?

Далее, циклы перезаписи чаще случаются непосредственно в служебных областях.

Это не hdd. Контроллер сам разберется

под SSD нужно бы основательно переписать INIT

Один уже написал, спасибо, не надо. Много они (скрипты) там пишут на винт? килобайты, от силы - мегабайты? Контроллер раскидает перезапись так, что один цикл перезаписи всех ячеек на винте такими дерганиями инита будет годами перезаписываться.

Я уж молчу, что при старте там еще шрифты обновляются, ldconfig, depmod...

А еще у меня в хомяке (который на ssd) кэш браузера. Бида-бида.

<название винта> в буке cдох за год

Может это брак, или технических подробностей не будет?

Орли? Я думал, они в LBA всё считают. Я бы глянул на smartctl -A /dev/sdX :3

Вообще-то я о том же)

# smartctl -A /dev/sda | grep -i write
241 Lifetime_Writes_GiB     0x0032   000   000   000    Old_age   Always       -       1303

1303/55.9 = 23,3 перезаписи за 3 мес. За год - 100.

При условии, что

A. на диске один раздел...

Один.

B. файловая система знает...

Ей достаточно знать про TRIM, остальным занимается контроллер.

А па~ру тысяч не хочешь?

Ок. 20 лет. Меня устраивает:-)

Meanwhile in hardware land there is a whole lot of logs writing on /var/log/.

Пусть пишут. Я выше привел статистику

12 самописных? кто-нить сырцы показал? или просто рука дрогнула когда нажимали «проголосовать»?

cat /sys/block/sd*/queue/scheduler

?

вопрос не точен, потому так:
если нет AHCI, то NCQ
иначе noop

Ей достаточно знать про TRIM

Скажи мне, милый ребёнок, а что делает команда TRIM?

Насколько я помню - помечает грязные страницы как свободные. А что тебе не нравится?

Насколько я помню - помечает грязные страницы как свободные.

Именно. А где в этом предложении ты увидел словосочетание 「равномерная перезапись」или 「предотвращение неравномерного износа」? TRIM — это всего лишь костыль, призванный компенсировать медленное и затратное блочное стирание стиранием загодя, 「в свободное время」. На ресурс ячеек это никак не влияет. Поэтому как писался лог по своим инодам, так и будет писаться туда до опупения. И ресурс тех блоков будет израсходован в разы быстрее.

Поэтому как писался лог по своим инодам, так и будет писаться туда до опупения. И ресурс тех блоков будет израсходован в разы быстрее.

hint: GC и алгоритмы равномерного износа в контроллере SSD.

Чукча не читатель, чукча писатель? Я же в двух постах несколько раз написал, что этим занимается контроллер.

Поэтому как писался лог по своим инодам

См. мою писанину выше. Не будет он писаться по тем же инодам.

Согласен. Много, кто не понимаю сути и поэтому говорят, что лучший выбор NOOP + NCQ. Так вот NCQ никакого отношения к сабжу не имеет и ничего о процессах не знает. Суть планировщиков в том, что они планируют запросы ввода/вывода процессов. NOOP предполагает, что запросы будут обрабатываться в порядке поступления. Например, если есть игра и процесс, порождающий массу подпроцессов (компиляция), то обработка I/O будет происходить очень несправедливо: игра, gcc, gcc, gcc, gcc, игра, gcc, gcc, gcc... Т.к. gcc процессов банально больше. BFQ учитывает иерархию процессов и способен обрабатывать такие ситуации, давая игре больший приоритет ввода/вывода, т.е. она будет чаще получать доступ к диску. По идее, Deadline может пригодится на серверах (на десктопах смысла в ней нет). Очевидно, что NOOP+SSD - бредовая идея. Кто ж будет управлять запросами ввода/вывода? Может, SSD настолько быстр, что игра не будет тормозить, но как только вы упретесь в скорости чтения/записи SSD, возникнет описанная выше проблема с игрой и компиляцией.

Deadline может пригодится на серверах (на десктопах смысла в ней нет)

У меня на десктопе deadline работает заметно более отзывчиво, чем CFQ/BFQ. Еще от ФС зависит. Та же btrfs любит CFQ.

Да от дедлайн вреда больше на десктопе. При высокой нагрузке на диски начинает тормозить всё. Включая тот процесс, который и делает много запросов к диску.

А вообще хороший, годный ответ.

hint: GC и алгоритмы равномерного износа в контроллере SSD.

Хорошо, я признаю, что был неправ насчёт того, что лог будет перезаписываться в тех же блоках. Однако сборщик мусора и контроллер ещё не гарантируют равномерной перезаписи, потому что

• алгоритмы сборщика мусора и выборки блоков для записи нигде не стандартизированы и отличаются от производителя к производителю;
  
• усердная сборка мусора в незанятое время может повышать износ ячеек свободного пространства;
  
• если блок постоянно переписывается, но при этом изменяется лишь какая-то его часть, он изнашивается быстрее. Контроллер может выделить неменяющиеся страницы блока в другой, отдельный блок, но это приведёт к другой проблеме — у нас будет область диска, которая не переписывается вообще, а нагрузка на оставшееся место возрастёт. И контроллер тут уже ничего не может поделать, потому что это дело VFS двигать файлы. И F2FS это умеет, а ext4 — нет.

Чукча не читатель, чукча писатель? Я же в двух постах несколько раз написал, что этим занимается контроллер.

Да, прости, я не знал, что контроллеры это умеют.
Кстати, у меня появился вопрос насчёт записанных гигабайт из SMART. У тебя этот параметр занимает номер 241, по которому обычно выводятся LBA. Но в случае с HDD нет разницы, а вот в случае с SSD — это преданные хостом контроллеру гигабайты, или гигабайты, записанные контроллером диска в процессе записи в память? Алсо, в SMART должны быть и параметры, явно указывающие его износ. Кстати, что за диск/контроллер? smartd настроен же?

Как я понимаю - считает контроллер. Есть и не один. Например имеется параметр ошибок записи, т.е. когда ячейка «все», и только ro. Не помню как называется, да и я уже дома комп вырубил, на 2 часа раньше ответил бы - глянул бы по ssh). SSD вот такой, 60-ка. smartd не настраивал.

У меня на десктопе deadline работает заметно более отзывчиво, чем CFQ/BFQ

Ext4 ?

А какая ФС ?

ext4.

Xfs

а если винт работает по AHCI с включенным NCQ, то разве нужен планировщик в ОС?

Никогда особо не задумывался, а наверное зря. Сейчас так:

find /sys/block -name sd? -print -exec cat {}/queue/scheduler\;
/sys/block/sda
noop deadline [cfq] 
/sys/block/sdb
noop deadline [cfq] 
/sys/block/sdc
noop deadline [cfq] 
/sys/block/sdd
noop deadline [cfq] 
/sys/block/sde
noop deadline [cfq] 
/sys/block/sdf
noop deadline [cfq] 
/sys/block/sdg
noop deadline [cfq]

вы не верите в правду?

Да, с ext4 deadline плохо работает, неэффективно.

Noop
Ибо SSD

На SSD, в отличие от HDD, время доступа одинаково для всех секторов, поэтому изменение порядка запросов не имеет смысла.

Для старых машин (медленных дисковых подсистем) лучше использовать anticipatory. Для современных - bfq, как мне кажется. Читайте описания каждого из шедулеров...

а для микроконтролеров с разными типами памяти?

«No such file or directory» считается? :)

noop deadline cfq [bfq] HDD

#>cat /sys/block/sdX/queue/scheduler
cat: /sys/block/sdX/queue/scheduler: No such file or directory
#>

как-то так

Тот, который выбрал Патрик.

find /sys/block -name sd? -print -exec cat {}/queue/scheduler\;

$ find /sys/block -name sd? -print -exec cat {}/queue/scheduler\;
find: отсутствует аргумент у «-exec»

BFQ + echo «20» > /proc/sys/vm/swappiness = ура, все просто летает!