Comments 38
del
какой смысл в копировании разделов, а не содержимого?
если копируется содержимое, то заодно получаем бесплатную дефрагментацию, улучшаем locality of reference (например, файлы из одного каталога оказываются расположены физически близко), избавляемся от «хвостов» и ошибок.
в ext4 и xfs, например, периодически добавляются новые фичи, оптимизируются дефолты; так что есть смысл пересоздавать файловую систему свежим mkfs.
Согласен, для Linux после выхода новой фичи у ФС, возможно, есть смысл скопировать. Хотя сам дисковый формат чрезвычайно стабильный. И, как правило, очень редко меняется. Фичи в основном на программном уровне. Единственную фичу на уровне формата я знаю для XFS. Ей нужен реформат для поддержки reflink.
Преимущества клонирования перед копированием:
1. Например, btrfs поддерживает снимки (снепшоты). И простое копирование будет копировать снепшоты как обычные файлы и забьёт диск-приёмник.
2. Скорость.
dd скопирует в разы быстрее, чем cp. Разница может быть в десятки, сотни и даже тысячи раз. Если на диске очень много мелких файлов.3. Копируется UID, служебная информация ФС. Это, конечно, мелочь. Его можно скопировать и отдельно. У той же ext2-3-4 есть интересная служебная информация касаемо статистики доступа к ФС. Например, число записанных гигабайт.
4. Копируются удалённые файлы. Если что-то было удалено, то после клонирования это можно восстановить. Для меня это плюс.
5. Для Windows я не знаю способа корректно скопировать абсолютно файлы, чтобы после этого диск остался загрузочным.
- разве у btrfs нет волшебного ключика вроде
zfs send-R? - да, скорость зачастую dd намного выше. но во многих случаях скорость пофайлового копирования вполне достаточна.
- вообще иметь две файловые системы с одним uuid — плохой тон. правильнее создавать с новым uuid и поправить конфиг бутлоадера/fstab.
- вы это серьёзно? (если честно, этот пункт пришлось не пропустить чтобы не сбилась нумерация в markdown)
- вот тут не специалист, разве для загрузки через efi/gpt подобные хаки ещё используются?
1. разве у btrfs нет волшебного ключика вроде zfs send-R?
Что-то подобное есть. Во всяком случае, для синхронизации снепшотов. Но оно будет по времени работать как копирование.
2. да, скорость зачастую dd намного выше. но во многих случаях скорость пофайлового копирования вполне достаточна.
Я тут недавно диск на 11ТБ клонировал. Копировал около 8 часов. Думаю, это заняло бы не меньше недели по-файлово.
3. вообще иметь две файловые системы с одним uuid — плохой тон. правильнее создавать с новым uuid и поправить конфиг бутлоадера/fstab.
Это же клонирование. От старого диска избавляются.
4. вы это серьёзно? (если честно, этот пункт пришлось не пропустить чтобы не сбилась нумерация в markdown)
Абсолютно. Недавно столкнулся с потерей очень важных данных. В таком случае посекторная копия может выручить. И выручила.
5. вот тут не специалист, разве для загрузки через efi/gpt подобные хаки ещё используются?
У Windows очень сложная система прав. Я использовал кучу разных ключей для xcopy и robocopy, но не смог заставить заработать скопированную Windows 7.
Работает send | receive с под-томами (а снапшоты — просто частный случай под-тома).
dd проиграют по скорости случайному чтению и наполовину случайной записи btrfs send. Я могу допустить, что если партиция заполнена на 10%, что это так, так как копируются только значащие данные. Или если вы у dd поставили малое значение блока, например, bs=4096.Но, скажем, на разделе, который заполнен на 90%, не могу представить случая, чтобы вы были правы. А ведь там не только копирование, но ещё и нагрузка на CPU, балансировка деревьев и т.п.
Но выиграть cp у btrfs send | receve не получится (скорее всего) даже на 10% заполнении раздела (и на hdd и на ssd).
Дело в том, что cp внутри себя пойдет через целую кучу системных библиотек. И читать будет много откуда в процессе своей работы. И при записи будет те же балансировки деревьев вызывать.
А вот btrfs send знает где что лежит и вытаскивает только то, что нужно и очень оптимальным для себя способом, а btrfs receve получает не только данные, но и метаданные, а по этому на записи он практически только пишет, ничего не балансируя. Правда по затратам оперативки в процессе работы btrfs send | receve потребует значительно больше чем cp. Но по доступам к диску cp проиграет однозначно.
Кроме того есть еще такая фишка btrfs как sparsed-files — длинные цепочки нулевых байт вообще на диске не хранятся. Только вот cp про это не знает и потянет кучу нулей там где btrfs send | receve передаст несколько байт.
Тоже касается и упаковки файлов — cp будет их распаковывать при чтении и запаковывать при записи, а btrfs send | receve просто прокинет такие файлы прямо в сжатом виде.
Собственно нужно понимать: btrfs send и btrfs receve — это специально оптимизированный инструмент для переноса данных под-тома.
Кроме того есть еще такая фишка btrfs как sparsed-files — длинные цепочки нулевых байт вообще на диске не хранятся. Только вот cp про это не знает
man cp говорит, что знает.
Тоже касается и упаковки файлов — cp будет их распаковывать при чтении и запаковывать при записи, а btrfs send | receve просто прокинет такие файлы прямо в сжатом виде.
патч такой был
https://lwn.net/Articles/829312/
но не вижу, чтобы он был применён
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/fs/btrfs/send.c
Интересно, если произошёл переход с 512В на 4КiB, то и разделы по идее придётся выравнивать?
У меня недавно задача была перенести Windows 10 с обычного диска на SSD. Вроде бы ничего такого. Сначала Clonezill'ой сделал образы. Потом используя parted попробовал создать требуемые разделы. Несмотря на то, что parted показывал логический/физический сектора как 512B/512B для оптимального выравнивания он же требовал выравнивать начало разделов кратным 65535 секторам. Понятно, что это было бы лучше с точки зрения производительности и долговечности накопителя. Поэтому пришлось немножко посидеть с калькулятором и создать таблицу разделов с некоторыми дырками между разделами, так как сами разделы я создавал по количеству секторов 1-в-1 как оригинал на HDD. Потом всё развернул, восстановил флаги разделов и оно у меня успешно заработало после небольшой правки в BCD (достаточно поправить ссылки на разделы параметров "Device" и "OS Device").
Если в 512b они выровнены, то не придётся. Но это зависит от возраста диска, точнее от времени, когда он первоначально разбивался.
На всех Windows после Windows XP установщик думает о кратности
а 16МиБ — чёрт знает что, просто заполнен нулями.
Это специальный раздел, используемый Windows для каких-то своих целей. По сути это некий выделенный в раздел RAW, так как никакой ФС там нет — тупо зарезервированное место и всё. Его даже можно и не клонировать по большому счёту, хотя я на всякий случай делал)
>На текущий момент ни одна утилита для клонирования не умеет корректно клонировать NTFS-раздел
Извините,но вы не правы.Есть утилиты фирмы Paragon, и они спокойно с обычного диска переносят на EFi диск с 4 кб,переделовая Ntfs (при этом еще можно размер или место раздела поменять).При этом можно указать чтобы пуское пространство и временные файлы не копировало.
И у Парагона нормально работают утилиты с линуксовскими разделами,нормально бэкапит, а то на конкуренте я обжогся,у меня был раздел ext4 с включенными екстентами,кашу вместо архива получил.Единственный недостаток-прикращают русские версии продуктов выпускать,нет покупателей.
Добавлю,давно не смотрел,оказываеться линукс утилиты направления здорово прикрыли-остались драйвера нтфс и серверные редакции.Но live диск на linux есть ,хотя по качеству упал,приходиться извращаться чтобы запустить на ноутбуке.
А я думаю, что вы неправы.
Вот информация из базы знаний Paragon о невозможности клонирования 512B -> 4K.
It’s possible to copy 512 to 512, and 4K to 4K. If values are not the same, then disk copy between these devices will not be possible.
Так это версия продукта 79,уже не потдерживаемая.
А сейчас 83 и выше
На странице я нигде не нашёл версии продукта 79. А 79 в УРЛ относится к номеру статьи.
Впрочем, если вы приведёте ссылку на то, что этлт функционал появился, буду рад.
Там хитрое иминования продуктов по версиям,нужно обращать внимание на внутреннию версию продукта.А так -https://www.paragon-software.com/ru/home/hdm-windows/#
Цитирую >операции с разделом или диском#
Изменение размера кластера, конвертирование в логический или первичный, редактирование секторов, сжимание и дефрагментирование MFT. Конвертирование в MBR или GPT, изменение очередности разделов,
Ещё один аргумент за кластеры размером 4 КБ — с другими размерами могут возникать внезапные проблемы в Windows.
Эх, не получилось на днях склонировать вин 10 через clonezilla: посыпались ошибки при загрузке которые винда была не в состоянии решить сама. Попробовал несколько раз, плюнул и поставил заново с переносом файлов. Если честно, бесит то как легко дают советы «просто использовать dd», там ничего сложного. А потом открываешь статьи как эта и видишь как это на самом деле.
Зы. Для желающих иметь универсальную загрузочную флешку — Ventoy в помощь www.ventoy.net/en/index.html Загрузил ВСЕ iso, что я ему подсовывал — даже HP SPP. Возможно, после установки прийдется отформатить флешку в NTFS\FAT32 — exFAT не все дистр-вы умеют (проверить?).
Зы2. Кому охота централизовано клонировать\развертывать снимки ОС и грузить iso по сети (PXE) — fogproject.org Этакий MS WDS. Умеет развертывать снимки большего размера раздела на меньший.
А что насчёт trim?
Если копировать с hdd на hdd - там неважно, если исходный диск/раздел пуст - ну, просто скопируются пустые нули (либо удалённые файлы). Понятие "свободное/занятое" место есть только в абстракции ФС, самому диску всё равно.
А вот если копировать на ssd (судя по характерным именам устройств с nvme в составе могу предположить, что речь именно о них) - то там понятие свободных/занятых областей есть ещё и в абстракции самого контроллера, и они важны для поддержания работоспособности и производительности. Свободная область - значит, при чтении контроллер не будет обращаться к чипам, а будет просто выдавать в шину нули. А при записи он просто выделяет место из пула свободных областей, не озабочиваясь их содержимым. Занулёная область - это область, ЗАНЯТАЯ нулями. Там при чтении уже надо честно читать чипы. И при записи уже нельзя просто сохранить файл в произвольное место, потому что всё место занято!
При недолгом поиске можно найти тулзы, которые позволяют сделать trim на фактически свободные области.
Многие распространенные «железные» raid-контроллеры НЕ УМЕЮТ trim в режиме raid. Следует об этом помнить. По этому на своих proxmox-ах пользую zfs для рейда и диски ТОЛЬКО в сыром виде.
Да как отвечают... Они просто выполняют команду. Но они не могут сами определить, нужные ли данные вы заливаете, или мусор. ОС должна эту команду вызвать, автоматической магии там нет. Сделайте бенч чтения с чистого ssd - получите, по сути, скорость шины. Залейте на чистый ssd нули через dd if=/dev/zero... - и результат чтения (нули) останутся прежними, а вот скорость уже будет отражать работу с чипами.
Возможно, какие-то контроллеры на текущий момент уже достаточно умные, чтобы автоматически спарсить нулевые данные. Но если вы через тот же dd заливаете не нули, а мусор от удалённых файлов (и при этом вам этот мусор не нужен, просто обнулить его было лень перед клонированием) - контроллер диска никак не сможет сам решить, нужное в него льют или нет; он просто запишет, что передали. И низкоуровневые команды вроде dd тоже этого знать не могут, они тупо передают сырые данные заданными кусками.
Не в курсе, исправили ли это в новых версиях движка, но во времена Win2K8 R2/Win7 это было весьма актуально.
Готов поставить плюс только за пикчу
Клонируем GPT-диск с 512B-сектором на диск с 4K-сектором в Linux. Подводные камни с EFI, NTFS и LVM