Как предотвратить тайм-ауты дискового ввода-вывода, которые приводят к отключению дисков и повреждению данных на дисках SMR?
Напишите свой собственный тривиальный сценарий оболочки и используйте его как./get-them.sh < get-then.list
сценарий оболочкиget-them.sh
#!/bin/sh
while read FILE URL; do
wget -O "$FILE" -- "$URL"
done
входной файлget-them.list
file1 https://unix.stackexchange.com/
file2 https://stackexchange.com/
Я изменил приведенные ниже параметры ядра, и диски SMR больше не отключаются при большой нагрузке записи. Иногда производительность записи резко снижается при интенсивном вводе-выводе (, например при скорости записи в однозначных МБ/с ), но диски, по крайней мере, больше не отключаются.
DEVICE=sdX # insert your device name here
echo 3600 > /sys/block/$DEVICE/device/timeout
echo 3600 > /sys/block/$DEVICE/device/eh_timeout
echo noop > /sys/block/$DEVICE/queue/scheduler
echo 1 > /sys/block/$DEVICE/device/queue_depth
echo 4 > /sys/block/$DEVICE/queue/nr_requests
Я не тестировал каждый из них по отдельности, поэтому не уверен, что требуется установка каждого из них, но эта комбинация работает для меня.
У меня есть хороший опыт использования F2FS, а не XFS или ext4 на дисках SMR. Мой ext4 продемонстрировал поведение, похожее на то, что вы описали выше, на моих дисках SMR и заставил меня исследовать решения SMR в Linux. Я также столкнулся с проблемами тайм-аута, которые вы описываете. Я также использую Ubuntu, но более позднюю версию Ubuntu 18.04.3 LTS.
Во-первых, я бы никогда не рекомендовал SMR-диски для серверов с большим количеством случайных операций чтения/записи. Примерами использования -случаев, когда вы хотите избежать использования SMR, могут быть приложения базы данных и NAS с высокой пропускной способностью чтения/записи. Мой вариант использования — для внешних резервных копий NAS, и это нормально, потому что это не критично по времени, а также в основном последовательно.
Первое, что нужно сделать, это получить файловую систему F2FS, что в версии 18.04 так же просто, как:
sudo apt install f2fs-tools
Используя gparted, удалите ВСЕ разделы с диска SMR, затем используйте gpartedдля создания раздела F2FS, охватывающего весь диск.
Мои диски (Toshiba )поставлялись предварительно отформатированными с двумя разделами для использования на компьютерах с ОС MS -Windows. Если бы я оставил маленький первый раздел, то скорость записи была бы ужасной, независимо от того, какую файловую систему я установил. Я сильно подозреваю, что первый раздел — это место, где часть диска, отличная от -SMR, выделена для использования в журнале и других метаданных. Мой опыт показал, что очень важно, чтобы созданная файловая система имела доступ к этой области, чтобы получить от нее пользу.
К сожалению, похоже, в gparted нет места, где я мог бы настроить параметры для правильного создания файловой системы, подходящей для диска SMR с блочной зоной. Отметив информацию, идентифицирующую раздел, я вышел из gpartedи вручную запустил команду mkfs,на этот раз добавляем волшебный соус:
sudo mkfs.f2fs -fm /dev/XXXX
где XXXX— ваш раздел, указанный ранее в gparted. Эта опция -m очень важна, так как она указывает F2FS использовать возможности заблокированной зоны диска SMR. Мой опыт показывает, что без него вы будете томиться в каменном аду.
Сделав это (и смонтировав ), запись на накопитель была достаточно последовательной. Я в основном получаю скорость записи от 117 МБ/с до 105 МБ/с. Очень редко на несколько секунд скорость записи падает до 70 -80 МБ/с.
Я подозреваю, что провал — это место, где SMR-диск должен наверстывать упущенное, переписывая -области диска, где есть перекрытие гальки. К счастью, это случается не так часто, хотя я признаю, что еще не (еще )не использовал и половины доступного места на жестком диске. Когда это произойдет, я ожидаю, что согласованная запись будет происходить чаще, и в результате резервное копирование займет больше времени. Тем не менее, прямо сейчас он очень хорошо справляется с тем, чтобы избежать покрытых черепицей областей пластины, и я изо всех сил пытался найти много примеров, демонстрирующих замедление. Похоже, что он также использует незанятые области устройства для своего журнала метаданных (), что позволяет избежать описанных вами значительных замедлений.
Я также заметил, что F2FS требуется около 10 секунд, чтобы очистить оставшиеся данные после завершения чтения и возврата командной строки. Важно не размонтировать устройство и не отключать его от сети в это время, чтобы избежать потери данных. Если вы используете сценарий оболочки, имейте это в виду.
Думаю, вы согласитесь, что мои скорости записи при использовании F2FS намного превышают те, которые вы продемонстрировали при использовании xfs. Кроме того, мне не нужно было менять какие-либо тайм-ауты, чтобы это сработало.