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

1. Вводные

Для сжигания дисков сервера у меня было:

выделенный сервер на базе ОС Debian 10 (x86_64) с Intel i7-7700 (8/16, 4.2 Ghz), 64 GB DDR4, 2-мя SSD-дисками по 480 GB от фирмы SPCC (Silicon Power) в Raid0



выделенный сервер на базе ОС Debian 10 (x86_64) с Intel i5-10600 (12/24, 3.3 Ghz), 32 GB DDR4, 2-мя SSD-дисками по 480 GB от фирмы Crucial (линейка BX500) в Raid1

2. Технические и другие особенности

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

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

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

1. Сначала была создана команда о которой я расскажу ниже
2. Потом эта команда была загружена в планировщик
3. Потом сервер сразу приступил к выполнению запланированных команд (после сохранения данных в планировщике)
4. Диски начали выполнять операцию бесконечной записи и перезаписи
5. После достижения лимита скорости на запись диска, сервер начал выносить операцию в оперативную память из-за чего она забивалась практически сразу
6. Процессор тратил до 50% своей мощности на обработку, в пике до ~~80%. Чем больше ядер — тем меньше нагрузка. Пиковая в ~~80% была замечена на сервере с i7-7700, 50% — i5-10600.
7. Диски с трудом выполняли операции по установке/записи любого конфига/пакета

3. Реализация

Бесконечные операции по перезаписи были реализованы при помощи “встроенного бенчмарка” dd. По сути эта программа создана чтобы что-то куда-то копировать, но для в этом случае я называю его “бенчмарком”.

Запланированные операции по перезаписи выполнялись при помощи “встроенного планировщика” crontab.

Команды которые были записаны в планировщик (надо открыть cron через команду “crontab -e” и в конце файла вписать команды ниже, нажать ctrl+s, потом ctrl+x / софтина сама сохранит конфиги и будет применять их):

0-59/3 0-23 * * 1-6 dd if=/dev/zero of=/tmp/upload1.img bs=2G count=10 oflag=dsync

0-59/4 0-23 * * 1-6 dd if=/dev/zero of=/tmp/upload2.img bs=2G count=10 oflag=dsync

0-59/5 0-23 * * 1-6 dd if=/dev/zero of=/tmp/upload3.img bs=2G count=10 oflag=dsync

0-59/6 0-23 * * 1-6 dd if=/dev/zero of=/tmp/upload4.img bs=2G count=10 oflag=dsync

0-59/7 0-23 * * 1-6 dd if=/dev/zero of=/tmp/upload5.img bs=2G count=10 oflag=dsync

0-59/8 0-23 * * 1-6 dd if=/dev/zero of=/tmp/upload6.img bs=2G count=10 oflag=dsync

Разбор команды:

0-59/3 0-23 * * 1-6 dd if=/dev/zero of=/tmp/upload1.img bs=2G count=10 oflag=dsync

Разметка для CRON:

• 0-59/3 — каждую третью минуту в промежуток между 0 минутой и последней 59 минутой часа
• 0-23 — в промежуток между 1 часом ночи вплоть до 24 часа дня (нумерация часов и минут идет с 0)
• * — каждый день
• * — каждого месяца
• 1-6 — в промежуток между 1 днем (понедельником) и 6 (воскресенем)

Разметка для DD:

• dd — мы выполняем команду dd
• if=/dev/zero — которая берет информацию с папки /dev/zero (папки для нулевых байтов, пустого места по сути)
• of=/tmp/upload1.img — и записывает в папку tmp файл upload1.img
• bs=2G — размером 2 Гигабайта (2048 Мбайт, лимит софта именно 2 ГБ)
• count=10 — десять раз подряд
• oflag=dsync — при помощи операции ввода вывода для данных (пустой записи, записывая постоянно НИЧЕГО)

Т.е учитывая команды выше, каждую каждую третью, четвертую, пятую, шестую, седьмую, восьмую минуту часа (безостановочно практически в течении каждого часа дня, каждого дня в течении недели, каждой недели) мы записываем 10 раз файл по 2 Гигабайта.

По памяти скажу, 2 Гигабайта записываются примерно за 12 секунд, 20 Гигабайт примерно за 2 минуты. Не давая серверу просыхать — он запускает следующую команду по перезаписи или делает её одновременно с другими файлами upload1-6.

4. Результаты

В результате, за 17 дней сервера записали следующее

сервер с i7-7700, 2 диска по 480 от SPCC в raid0:

• 1046857341958 — Logical Sectors Written (диск 1)
• 1047262883822 — Logical Sectors Written (диск 2)

сервер с i5-10600, 2 диска по 480 от Crucial BX500 в raid1:

• 3774163804 — Logical Sectors Written (диск 1, по отдельности)
• 3943423199 — Logical Sectors Written (диск 2, по отдельности)
• 102570407494 — Logical Sectors Written (СУММАРНО)

В raid0 — диски подключены как одно целое, в raid1 — первый основной, второй дублирующий (зеркальный массив)

В каждом диске, согласно smartctl -a /dev/sd(a/b) — размер сектора 512 байт. В итоге согласно формуле c interface31.ru мы имеем:

1. (1046857341958*512)/1024/1024/1024 — 499180.47 ГБ (i7-7700)
2. (102570407494*512)/1024/1024/1024 — 48909.38 ГБ (i5-10600)

Делим ещё раз на /1024 и получаем:

1. 499180.47/1024 = 487.48 ТБ
2. 48909.38/1024 = 47.76 ТБ

Расчет формулы:



Число 512 мы берем из команды «smartctl -a /dev/sd(a-b)». Нам важен «Sector Size» (по умолчанию для SSD).

1. (X*512)/1024/1024/1024 — для результата в ГБ
2. (X*512)/1024/1024/1024/1024 — для результата в ТБ
3. (X*512)/1024/1024/1024/1024/1024 — для результата в ПБ

Итого мы имеем:

• Диски от SPCC имеют лимит записи до ~~500 ТБ в raid0
• Диски Crucial BX500 имеют лимит нормальной записи вплоть до ~~50 ТБ в raid1 после чего начинают дико тормозить

Условия подсчёта:

• в дисках с RAID0 — надо брать инфу про итоговое кол.во записанных секторов при помощи команды smartctl -x /dev/sd(a-b), ибо в smartctl -a /dev/sd(a-b) показывается кол.во секторов по дискам ОТДЕЛЬНО
• в дисках с RAID1 — надо брать инфу в smartctl -a /dev/sd(a-b), в smartctl -x /dev/sd(a-b) информация по кол.во записи показывается ПО ОТДЕЛЬНОСТИ

5. Итоги

Лично для себя я понял, что Crucial`ы конечно хороши, но все таки это дешевые ССДшники. Потом куплю новую материнку и обновлюсь до NVMe от Samsung. Если по делу — технически сжечь диски невозможно.

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