Имеет ли смысл разбивать HDD с TRIM на быстрый и медленный разделы?

Как раз сижу на raid0 встроенный в btrfs. Два ssd, один на два года старше другого. Что может пойти не так?

И без бэкапов? :)

Скажем так, RAID0 — это действительно специфическая вещь.

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

Отличный повод перейти на SSD, хотя бы SATA. Поверь, тебе понравится.

Обожаю SSD, но для хранения серии полных бэкапов их цена для меня неприемлема. Мне нужен объем от 5 ТБ. И таких носителей должно быть два на случай, если при очередном подключении один из них окажется мертвым.

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

Временами делаю.

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

Когда-то этот трюк имел смысл. Но, скорее всего, смысла уже не имеет для большинства современных дисков. Причина: производители в разных целях используют таблицы трансляции LBA-PBA. Судя по тенденциям, они будут только расширять их использование. Это никак не связано ни с TRIM, ни SMR. TRIM тоже не имеет прямой связи с SMR. Жесткий диск уже не будет настолько простым и понятным устройством, как раньше. Зависимость логических адресов от физических может быть довольно сложной в зависимости от задач, под которые оптимизирована прошивка контроллера.

Основывать выбор диска на этой характеристике смысла не вижу.

Правильно ли я понимаю, что диски для видеонаблюдения не имеют SMR?

Снова отвечу сам себе. Одно с другим не связано. Но в дисках для видеорегистраторов негативные эффекты от использования SMR сведены к минимуму, т.к. запись производится преимущественно последовательно без лишних движений головы, переупорядочивание уже записанных данных не выполняется никогда, и лишь в исключительных случаях производится чтение старых сильно разреженных лент/дорожек с целью их перезаписи вместе с новыми данными. Основная магия производится в таблице трансляции LBA-PBA, хранящийся в Flash-памяти.

По моему скромному мнению, для относительно быстрых полных бэкапов на HDD идеальными выглядят именно диски для видеорегистраторов. Они действительно оптимизированы для быстрой записи и ни для чего другого. Количество одновременных потоков записи и возникающая при этом фрагментация данных почти не принимаются контроллером в расчет. Дефрагментация данных средствами операционной системы на таких дисках не только бесполезна, но и вредна.

TRIM таким дискам полезен даже в отсутствии SMR, ускоряя поиск если не полностью пустых областей, то хотя бы сильно разреженных. Это позволяет минимизировать перезапись ранее записанных данных.

В простейшем случае у SMR есть большая не SMR-область на блинах, которая используется для кеширования/перезаписи зоны.

Есть еще один простейший случай: последовательная запись в ленты как на дисках для видеорегистраторов. Если верить слухам, WD использует именно такой подход, дополняя его фоновыми алгоритмами.

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

В моем сценарии использования дисков фрагментация пренебрежимо мала. Соответственно, скрытая магия по перетасовке данных будет быстрой и является необязательной. Поэтому диски можно отключать сразу после записи очередного архива. Скорость чтения для меня почти не важна. А скорость записи не будет существенно деградировать, т.к. деактуализация данных будет происходить большими блоками.

Вывод: бояться SMR-дисков в моем сценарии использования не надо. По крайней мере, дисков WD.

Контроллер диска с кешами уже давно изолирует «физику» от «логики» практически полностью.

Спасибо. Я эту фразу воспринял не сразу, но она ключевая для понимания проблемы. Логика жестких дисков продолжит все сильнее отрываться от физики вне зависимости от SMR.

Экспериментировть, конечно, хорошо, но одиночный экземпляр мало что даст.

Тест элементарный и быстрый:

• Запрашиваем TRIM для всего диска.
• Пишем по 1 GB в младшие адреса, средние и старшие, измеряем время.

Проверил для одного из SMR-дисков. Любопытно, что у него скорость линейного чтения практически не зависит от адреса. Зато скорость линейной записи зависит ощутимо:

• 1 ГБ информации в начале диска можно записать за 8 секунд;
• в середине диска за 11 секунд;
• в конце диска за 19 секунд.

Средняя скорость записи в младшей и старшей половине диска отличаются в 1.6 раз. Соответственно, файл размером 200 ГБ в младшую половину будет записан в среднем за 30 минут, а в старшую за 50. Это заметная экономия времени в описанном мной сценарии использования.

Выводы:

• Старый трюк с разбиением HDD на быстрый и медленный разделы все еще работает, выигрыш во времени записи может быть значительным.
• Экономия времени все равно не радикальная, нужно стремиться к автоматизации бэкапа.

А накопителю между записями давали время подумать? А лучше TRIM и в обратном порядке — сначала в конец, потом в середину, потом в начало. А то, может, он первый гиг записал в кеш, второй гиг наполовину в кеш, наполовину чистил кеш, а третий пришлось весь писать очищая кеш.

Ну и, по-хорошему, нужно написать модель/версию пошивки, чтобы другие знали.

скорость линейного чтения практически не зависит от адреса.

Там ходят страшилки, что скорость линеного чтения не зависит от адреса, но зависит от того, записывали диск последовательно или случайной записью и в последнем случае, если весь НЖМД записать, то скорость чтения может стать на уровне 10-20 Мбайт/с.

А накопителю между записями давали время подумать? А лучше TRIM и в обратном порядке — сначала в конец, потом в середину, потом в начало. А то, может, он первый гиг записал в кеш, второй гиг наполовину в кеш, наполовину чистил кеш, а третий пришлось весь писать очищая кеш.

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

Следом за коротким ручным экспериментом я запустил скрипт, перезаписывающий диск полностью: первый раз последовательно от начала и до конца; второй раз сначала последовательно старшую половину диска, а затем последовательно младшую. Перед началом записи обязателен запуск blkdiscard. Данные для записи взяты из /dev/urandom.

Графики записи (адрес; время) в обоих случаях практически идентичны. Совпадает даже адрес самого из значительных провалов в производительности ближе к концу диска. Адреса измерены в GiB.

Ну и, по-хорошему, нужно написать модель/версию пошивки, чтобы другие знали.

Если это кому-то принесет пользу, вот данные подопытного (диск куплен около 3 лет назад):

  Model Family:     Western Digital Blue Mobile (SMR)
  Device Model:     WDC WD20SPZX-00UA7T0
  Firmware Version: 01.01A01

Поведение этого диска не совпадает с утверждением о том, что SMR-диски WD записывают данные последовательно от начала к концу. Конкретно эта модель пишет ленты по фиксированным адресам или в особых случаях преимущественно фиксированным.

Там ходят страшилки, что скорость линеного чтения не зависит от адреса, но зависит от того, записывали диск последовательно или случайной записью и в последнем случае, если весь НЖМД записать, то скорость чтения может стать на уровне 10-20 Мбайт/с.

Страшилки понятны и обоснованы, в них нет загадки. Но я не нахожу обоснования, почему скорость чтения не зависит от адреса. Скорость на уровне 120-130 МБ/сек мог бы резать контроллер, но зачем? К тому же после TRIM диск выдает «данные» со стабильной скоростью 260 МБ/сек.

Графики записи (адрес; время) в обоих случаях практически идентичны. Совпадает даже адрес самого из значительных провалов в производительности ближе к концу диска. Адреса измерены в GiB.

Это не совсем так. Приведя графики записи к единому масштабу, я обнаружил расхождение в одном месте — это небольшой провал в скорости записи в середине диска практически на стыке половин: провал на первом гигабайте второй половины и почему-то не на последнем, а предпоследнем гигабайте первой половины. Время записи 13 секунд против 10-11 в соседних гигабайтах.

Из этого можно сделать вывод, что эта модель диска не пытается выполнить запись на максимальной скорости, а попросту перезаписывает ленты, содержащие данные, что соответствует классическим алгоритмам SMR-дисков. Значит, данные фрагментированы не будут. Зато будет медленной случайная запись.