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

но вроде бы многие отпсывают что это так...

Уже выяснил. Да - это так. И в минте тоже. Зато теперь понятно откуда растут ноги мифа о тормознутости убунту. Хотя факторов может быть гораздо больше.

~12 за 6 месяцев. Колво циклов ~3k вроде бы у этого диска.

Device Model: KINGSTON SVP200S37A240G

несколько самописных, которых меняю на лету в зависимости от задачи

OCZ Vertex 3 на 60 GB. Модель не вспомню. Меньше обьем, потому больше циклов. Время наработки обещают 2 млн часов и >50k iops (точные спецификации не помню)

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

$ uname -r 3.5.0-32-generic

Оппа. Сегодня привезли мне заказанный SSD для домашнего ноута. Сегодня походу буду систему ставить или копировать. Правда там для тестов система стоит сейчас. Так что думаю поставить с нуля. А тот HDD использовать как внешний (темболее SSD приехал с USB адаптором).

По тому что я читал - все эти опасения про время наработки - устаревшая инфа 5-ти летней давности. Т.е. на современных ssd:

1) Используем планировщик, т.к. ему виднее, как оптимальней рулить i/o

2) Используем современные ФС (ext4 с журналом + options «discard») - хоть не люблю я ее, но она все же неплоха.

3) Не менее 40% свободного места, чтобы не насиловать перезаписью одни и те же ячейки

4) Критический размер свободного места - 25%. Если меньше, то это еще более активное заелозивание определенной части ячеек.

Если кто-то думает, что винт так быстрее подохнет - моя гента на 60-гиговом (реальных ~55,8 гиг + где-то 1 гиг зарезервирован) будет жить как минимум 100 лет. Хомяк кстати тоже на этом же винте (с кэшем браузера, который постоянно обновляется, ага). Занято порядка 20%.

Вот, нашел статью: http://emulek.blogspot.com/2013/04/ssd.html - многабукаф, но как по мне весьма подробно разжевано

надо было добавить ответ «хз»

А где вариант:

cat: /sys/block/sdX/queue/scheduler: Нет такого файла или каталога

 dmesg | grep scheduler
[    1.816359] io scheduler noop registered
[    1.816360] io scheduler deadline registered
[    1.816378] io scheduler cfq registered (default)

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

зачем мне это нужно знать?

тебе незачем.

JaJa!

noop, т.к. доверяю планировщику(или кто он там?) NCQ в контроллере

Пока что ssd ещё нет, так что cfq. Потом скорее всего будет что-то ещё, возможно noop+zfs(on linux)

BFQ. Ибо при высоком I/O ничего не тормозит. :)

Даже как-то играл в первый Portal без потерь FPS, обновляя генту. А при компиляция, как известно, хорошо диск грузит.

На андроиде BFQ

cat: /sys/block/sdX/queue/scheduler: Нет такого файла или каталога
О чём вообще речь, и что я должен был увидеть?

Мне кажется, данный опрос - офигенный детектор дибилов. Все правильно сделал, splinter. Результат не важен, важны коменты. Иногда интересно поближе узнать публику на ЛОРе :)

где то читал что Deadline как бы лучше, но разницы не разглядел. вроде копирование файлов должно быть быстрее

taz@think ~ $ cat /sys/block/sdX/queue/scheduler
cat: /sys/block/sdX/queue/scheduler: Нет такого файла или каталога

Это другой, да?

noop [deadline]

Это другой, да?

Это петросянщина.

Это петросянщина.

Это не умение заменить один символ, скорее.

А при компиляция, как известно, хорошо диск грузит.

=D

Где вариант «Понятия не имею, мне честнагря пофигу» ?

А в убунте у меня по умолчанию deadline.

количество записаной инфы, GB

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

Делим это значение на емкость винта

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

1. на диске один раздел или размерами прочих разделов в сравнении с объёмом диска можно пренебречь;
2. файловая система знает про то, где она находится и старается равномерно осуществлять перезапись.

При этом я не слышал, чтобы ext4 как-то размазывала файлы по диску, экономя его ресурс. Полагаю, как раз из-за этого Samsung и начал разрабатывать свою F2FS, которая нынче уже допилена.

Судя по разным источникам, количество циклов записи - одни пишут 10к, другие 30-40к.

А па~ру тысяч не хочешь? Для MLC вполне нормально :3 Но это нижний предел, с которым я встречался, сейчас может и побольше. Правду может раскрыть только даташит к микрухам памяти внутри SSD. Если мне память не изменяет, были программы, вытаскивающие данные о производителе и типе микрух памяти через контроллер. Но это давно было, я ещё под вендами тогда сидел.

ext4, с журналом, как положено, почти дефолтные настройки

Настроек, положительно влияющих на износ SSD у ext4 нет. Разве что журнал на другой диск вынести.

в оперативке болтается разве что /tmp и /var/tmp (там же происходит сборка пакетов).

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

Рекомендую
http://ru.wikipedia.org/wiki/TRIM
https://wiki.debian.org/SSDOptimization

Лол, даташиты читай, а не поню обкуренную.

Напрасно лолкаешь, там поня много правильного написал.

А что такого?) Куча файлов пишется/удаляется, вполне быть.

А в андроиде у меня по умолчанию cfq. :)

Убунта тестовая?

Там 80% — пересказ википедии и манов с щедрой порцией отсебятины и 20% — размышления на тему. TRIM как панецея и 「ВЫ МУЧАИТЕ СВОЙ СЫСЫДИСК!」 особенно радуют.

Ошибаешься, дружище. Подохнет намного раньше.

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

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

Кроме того, настоятельно рекомендую посмотреть INIT-скрипты на предмет, чего они перезаписывают (а перезаписывают, как выясняется, много чего). По-сути, под SSD нужно бы основательно переписать INIT, скидывая (ну или симлинками) всякие там /tmp, /var/tmp, /var/run и т. д. в tmpfs

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

В общем, даже под линуксом, даже с вычищенными INIT-скриптами, даже с перенесенными на SD-карточку /root и /home, SSD (http://www.nix.ru/autocatalog/ssd_ocz/SSD_mSATA_OCZ_Nocti_NOCMSATA120G_MLC_12... такой вот) в буке cдох за год.

Кстати, в этом отношении моя абсолютно не понимать фанатов всяких там ультрабуков. У которых SSD напаяно на мать.

Год активной эксплуатации - и замена SSD ценой в материнку. Очень разумная трата денег!

Нет, 13.04.

Если тебе попался брак - меняй по гарантии. Год - это мало.

Как много извращенцев в опросе.

По ссылке:

«Ресурс SSD 0.096 петабайт (96 Тб) (3K циклов стирания/записи) - данные из неофициальных источников»

3000 циклов стирания/записи.

Даже при аккуратной эксплуатации (а я это делал аккуратно), набрать 3000 циклов за год не так уж и сложно. Одно только форматирование и установка ОС сколько сожрет? А чистка INIT-скриптов? А обновления? А включения-выключения?

В итоге «bad-block'и» в файловой системе - и всё. Прямо цепочка секторов подряд где-то с номерами от 200к до 240к. Бук-то работает. fsck ругается. Если переформатировать с проверкой на bb - может и очухается. Но всё-равно быстро посыплется в другом месте наверняка.

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

cfq для sata1, noop для остального.

Тебе гарантию дают, что винда-7 там работает 3 года. В чём проблема? MTBF 2 млн. часов...

Продолжай считать циклы.

cfq для sata1, noop для остального.

Как-то пробовал и noop, на cfq тоже поездил. Разницы нет. По советам лучших собаководов поставил себе на SSD deadline (раньше noop использовал) - пофигу, одинаково. Вот так и сижу: cfq для hdd, deadline для ssd. Не знаю, работает.

Если разницы нет - лучше ставить noop (меньше нагрузка на процессор).

На SSD - noop, на HDD - bfq.

SIO, NOOP (ANDROID)
CFQ, NOOP (PC x86)

Это всё личные мокренькие ассоциации. Никто не может точно ничего сказать.

The dumb «noop» scheduler may be a little faster in benchmarks that max out the throughput, but cause noticeable delays for other tasks when large file transfers are going on.

Поэтому дебианисты олдовые рекомендуют deadline.

NOOP (ANDROID)

Просто потому, что у меня в ядре (моего тела) только noop и cfq скомпилено. И не надо умничать, жрём, что дают.