LINUX.ORG.RU

SSD, резервное копирование с помощью dd

 , ,


0

1

Доброго времени!

Вопрос на понимание, должно быть глупый.

Одна из возможных реализаций резервного копирования - создание образа всего пространства накопителя с помощью команды dd.

Обратная процедура - восстановление данных - в случае SSD приведёт к тому, что контроллер накопителя будет считать все ячейки пространства занятыми (даже если они будут свободны с точки зрения ОС).

Является ли такое использование команды dd противопоказанным для SSD с точки зрения производительности?

★★
Ответ на: комментарий от xorik

Дело в том, что dd позволяет копировать структуры более низкого уровня чем файловые системы - таблицы GPT/MBR и LVM - что бывает удобно.

Как бы там ни было, dump/restore, tar, rsync, Bacula и другие инструменты, разумеется, имеют свою область применения, но вопрос не об этом.

dumka ★★
() автор топика
Последнее исправление: dumka (всего исправлений: 2)
Ответ на: комментарий от dumka

Скорее всего при записи блока, ssd будет считать его использованным, даже если там не было данных на ФС, что может пагубно повлиять на скорость работы.

Для проверки можно создать небольшой раздел, и запустить на нём trim_test.sh (легко гуглится)

xorik ★★★★★
()

полагаю, что в худшем случаи сначала ssd будет считать весь объем занятым и не будет trim, но по мере удаления файлов trim начнет работать

т.к. восстановление процедура не частая, ничего плохого для ssd не будет

x905 ★★★★★
()

В принципе, комманду TRIM можно отдать и потом: hdparm --trim-sector-ranges или --trim-sector-ranges-stdin Только вот надо олучить список пустых секторов, что может быть далеко не тривиально и зависит от типа файловой системы. hdparm --fibmap может немного помочь в этом деле.

ArtSh ★★★
()

возможно в этом случае поможет fstrim

Rost ★★★★★
()
Последнее исправление: Rost (всего исправлений: 2)

Всё понял. Спасибо за ответы.

dumka ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.