amarao

В линуксе самым очевидным индикатором утилизации дисков является flight_time. Если делать замеры каждую секунду, то разница между начальным и конечным значением покажет, сколько секунд в течение секунды диск был занят (значение обычно от нуля до 1).

Находится оно в /sys/block/sdX/device/stat (значение всех этих цифр - в Documentation исходников ядра).

На бытовом уровне - если блочных устройств мало, то просто atop (и дать секунд 11-12 отстояться) - и там будет показана утилизация диска.

Если блочных устройств много и они не влазят в вывод атопа, то я написал отдельно для себя простенький top по блочным устройствам https://github.com/amarao/blktop

Если нужно собирать эти метрики в автоматическом режиме, то обычно у соответствующих приложений (например, munin или ganglia) есть модули, которые эту информацию собирают.

SAS имеет смысл только из-за multipath'а. Если он не нужен, то SATA (в большем количестве) за те же деньги даст большую скорость.

(как человек, знающий откуда это «read only» вылазит)

В R/O файловая система сваливается из-за сбоев диска. Обычно это таймаут операции записи/чтения (для виртуальной среды). Обычно это происходит по одной из двух причин:

* таймаут iscsi инициатора у хостера
* свой собственный таймаут внутри операционной системы (около 2м)

Что делать?

а) уточнить у саппорта, можно ли перезагружать машину. В некоторых случаях это крайне нежелательно (например, если в этот момент запущен скрипт хостера на перезапуск, может случиться казус с ребутом во время fsck).
б) ребутнуться.

Если сбой был мягкий (т.е. просто остановка в обслуживании), то лёгкий fsck и всё хорошо. Если нет — по обстоятельствам. Соглашаться с всем напролом с fsck (без предварительного бэкапа) не стоит.

Совет выше насчёт smartmon'а не актуален — у виртуальных дисков нет смарта.

В будущем, возможно, может помочь опция panic в опции монирования. В этом случае при дисковых ошибках система уйдёт в панику (т.е. в ребут).