От: Копировать раздел в GParted (От темы с ID: 135133)

[drBatty]

P. S. Я бы сделал через dd.

как вы сделаете dd клон маленького диска на большой?

"Лучше" я имел ввиду практично и легко)

1. создать на большом диске разделы и ФС
2. скопировать таром (сжимать в stdout, и сразу разжимать из stdin)
3. поправить загрузчик.

[alv]

как вы сделаете dd клон маленького диска на большой?

это из маленького диска большой сделать затруднительно
а из большого маленький - как 2bs через dd переслать

поправить загрузчик

А Вы уверены, что в данном случае это будет быстрей, чем переставить ось? Ведь это самому править придётся, а при переустановке инсталлятор всё сделает.
А по пунктам 1 и 2 - согласен, всё правильно, так и надо
только с данными и конфигами, а не со всем на свете

[drBatty]

это из маленького диска большой сделать затруднительно
а из большого маленький - как 2bs через dd переслать

шутить изволите`с?

А Вы уверены, что в данном случае это будет быстрей, чем переставить ось?

нет.

Ведь это самому править придётся, а при переустановке инсталлятор всё сделает.

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

А по пунктам 1 и 2 - согласен, всё правильно, так и надо
только с данными и конфигами, а не со всем на свете

можно и всё вместе, если речь только про систему. Естественно /home/* нужно сохранять селективно.

[Rootlexx]

как вы сделаете dd клон маленького диска на большой?

А в чём проблема?

[drBatty]

А в чём проблема?

наверное ТСа не порадует, когда его терабайтник станет 100Гб диском. Но если ему это понравится, то всё ок.

[alv]

шутить изволите`с?

ага
ну не рыдать же над тем, что

терабайтник станет 100Гб диском

а ведь вполне реальная перспектива

[Rootlexx]

А в чём проблема?

наверное ТСа не порадует, когда его терабайтник станет 100Гб диском. Но если ему это понравится, то всё ок.

От этого он не станет 100 ГБ диском. Да, на нём после этого будет занято 100 ГБ, ну так и что с того? gparted в зубы - и вперёд делать так, как хочется.

[drBatty]

gparted в зубы - и вперёд делать так, как хочется.

а данные не потеряются от такого ресайза?

[Rootlexx]

а данные не потеряются от такого ресайза?

Нет.

[drBatty]

Rootlexx
ну если Вы гарантируете, то я за ТСа спокоен (хотя сам всё равно буду тарить)

[alv]

а данные не потеряются от такого ресайза?

Нет.

Данные скорее всего не потеряются. Если только в процессе не пропадёт питание, например.
Да вот только всё это вместе (и dd, и ресайсинг) займёт времени куда больше, чем переустановка системы и растаривание чего нужно.

[Rootlexx]

ну если Вы гарантируете, то я за ТСа спокоен (хотя сам всё равно буду тарить)

Естественно, катастрофические случайности я не учитываю. Ибо им подвержены все стадии процесса, включая tar.

Данные скорее всего не потеряются. Если только в процессе не пропадёт питание, например.

Если пропадёт питание, то потеряются любые данные, которые "в процессе".

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

Время копирования 100 ГБ данных при использовании dd на современных дисках составляет меньше получаса; время изменения размера раздела "вправо" (ещё не факт, что это требуется, ибо автор хочет, цитирую, "зеркальную копию") - это время изменения нескольких чисел в заголовке ФС и таблице разделов - несколько секунд от силы.
При переустановке же системы придётся заново отвечать на вопросы установщика, ждать, пока завершится установка (сильно зависит от дистрибутива и метода установки), потом установить все нужные программы (упираемся в скорость подключения к Интернету), затем внимательно развернуть все нужные конфигурационные файлы, модифицируя их при необходимости (fstab, ...), а также специфичные для дистрибутива параметры (в Debian - базу debconf, настройки alternatives, ...), после чего наконец можно приступать к копированию пользовательских данных. Да, выглядит очень быстро.

[drBatty]

Естественно, катастрофические случайности я не учитываю. Ибо им подвержены все стадии процесса, включая tar.

неправильно. Если вы тарите, то в любой момент может произойти авария, и это не повлечёт за собой потерю данных. Вам нужен RO доступ к источнику, и потому этому источнику ничего не угрожает(кроме физического уничтожения). Как только копия сделана, можно уничтожать и источник и цель (но не оба сразу конечно).

Т.ч. мой подход учитывает и катастрофы, которые IRL сплошь и рядом (батарейка в ноуте села например).

Если пропадёт питание, то потеряются любые данные, которые "в процессе".

дык у вас в процессе ВСЕ данные. А у нас -- только копии данных. Потому ваш подход неприемлем без бекапов, а с бекапами не имеет смысла(потому-как наш подход -- это и есть создание бекапа).

Время копирования 100 ГБ данных при использовании dd на современных дисках составляет меньше получаса

можно подумать, что tar будет работать медленнее. Быстрее и намного, если на диске есть пустые и/или сжимаемые области. А вот dd тупая, и копирует всё без разбора.

ещё не факт, что это требуется, ибо автор хочет, цитирую, "зеркальную копию"

ИМХО автор не олигофрен, и не нуждается в терабайтнике, отформатированном как 100Гбайтник.

это время изменения нескольких чисел в заголовке ФС и таблице разделов - несколько секунд от силы.

Щаз! Это вам все блоки с инодами по новой переделать, добавить новых инодов и раскидать заново по всему диску. Даже если ваш гпартед и справится, то очевидно будет долго стрекотать головками, ибо это не последовательная, а рандомная запись по всей поверхности множества мелких блоков. Она по времени не сильно быстрее последовательной. Ну а если у вас вправду "5сек", то значит ваш гпартед не осилил наделать и распределить новых инодов, и велик риск, что их тупо не хватит. Это очень сильно "обрадует" ТСа, когда через месяц у него будет 300Гб свободного места, на котором не создать ни единого файла.

потом установить все нужные программы (упираемся в скорость подключения к Интернету)

они в кеше лежат. Да, все новые последние версии. А если и не лежат, то программу всё равно давно пора обновлять.

[Rootlexx]

drBatty
Может, вы сначала прочитаете, на что я отвечал, прежде чем писать мне что-то в ответ? Я, между прочим, комментировал способ alv "переустановить систему, а потом выборочно переносить данные".
Теперь по пунктам.

неправильно. Если вы тарите, то в любой момент может произойти авария, и это не повлечёт за собой потерю данных. Вам нужен RO доступ к источнику, и потому этому источнику ничего не угрожает(кроме физического уничтожения). Как только копия сделана, можно уничтожать и источник и цель (но не оба сразу конечно).

Т.ч. мой подход учитывает и катастрофы, которые IRL сплошь и рядом (батарейка в ноуте села например).

А как по-вашему работает dd?
Блоки исходного носителя просто копируются на назначенный носитель. Естественно, исходные данные при этом никуда не деваются. tar здесь не предлагает ничего нового.
То же самое касается и возможного расширения раздела: все операции будут производиться с копией исходных данных на втором диске.
Поэтому это:

дык у вас в процессе ВСЕ данные. А у нас -- только копии данных. Потому ваш подход неприемлем без бекапов, а с бекапами не имеет смысла(потому-как наш подход -- это и есть создание бекапа).

- даже комментировать не буду.

можно подумать, что tar будет работать медленнее. Быстрее и намного, если на диске есть пустые и/или сжимаемые области. А вот dd тупая, и копирует всё без разбора.

Зависит от заполненности ФС.
Кроме того, доступ к диску через ФС априори медленнее прямого доступа. И разница вполне ощутима.

ИМХО автор не олигофрен, и не нуждается в терабайтнике, отформатированном как 100Гбайтник.

Не бросайтесь терминами, значения которые не понимаете. 4 * 16 байт в MBR не имеют никакого отношения к форматированию диска.

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

Феерично.
Вот вам загадка: как mkfs умудряется создать файловую систему ext4 размером 100 ГБ за 10 секунд, если ей для этого, как вы утверждаете, требуется пробежаться по всему диску, да ещё и "рандомно"?

Ну а если у вас вправду "5сек", то значит ваш гпартед не осилил наделать и распределить новых инодов, и велик риск, что их тупо не хватит.

А ничего, что gparted использует вполне себе официальные программы resize*fs для этой работы? Давайте, расскажите нам об их фатальных недостатках.

[drBatty]

Уважаемый Rootlexx, у нас здесь "вопрос новичка", а предложенный вами способ является деструктивным, и потенциально ненадёжным. Я понимаю, что вы принимаете все необходимые меры, и у вас ВР. Однако. Никто не знает, сохранит-ли ТС источник, и не поверит-ли Вам, что "это просто и безопасно"? Вы ничего про сохранение не говорили. Для вас наличие бекапа само собой разумеется, а вот для ТСа -- не обязательно.

Вот вам загадка: как mkfs умудряется создать файловую систему ext4 размером 100 ГБ за 10 секунд

всё очень просто: для создания пустой ФС нужно просто создать место для 100500 инодов. Т.е. сделать несколько десятков блоков с ними (ЕМНИП они по 32768 штук в блоке). Но если у вас _уже_ есть 100500 файлов, то задача _существенно_ осложняется.

ИМХО автор не олигофрен, и не нуждается в терабайтнике, отформатированном как 100Гбайтник.

Не бросайтесь терминами, значения которые не понимаете. 4 * 16 байт в MBR не имеют никакого отношения к форматированию диска.

в данном случае, под словом "отформатированно" я имел ввиду файловую систему определённого размера. EXT4 это вам не fat16, её ресайз не тривиален в случае, если она заполнена нужными файлами. Алгоритмически задача не слишком сложна, но её решение не сводится к тому, что-бы переписать десяток цифирек.

А ничего, что gparted использует вполне себе официальные программы resize*fs для этой работы? Давайте, расскажите нам об их фатальных недостатках.

С удовольствием: чем сложнее система, тем сложнее и дольше её менять. Всегда ваш К.О.

Если по вашему EXT4 проста, то вы про неё просто ничего не знаете.

[Rootlexx]

предложенный вами способ является деструктивным, и потенциально ненадёжным. Я понимаю, что вы принимаете все необходимые меры, и у вас ВР. Однако. Никто не знает, сохранит-ли ТС источник, и не поверит-ли Вам, что "это просто и безопасно"? Вы ничего про сохранение не говорили.

Во-первых, я никаких способов не предлагал. Использовать dd предложил Kopilov, а затем его поддержал Bizdelnick. После этого вами был задан вопрос:

как вы сделаете dd клон маленького диска на большой?

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

А как по-вашему работает dd?
Блоки исходного носителя просто копируются на назначенный носитель. Естественно, исходные данные при этом никуда не деваются.

О какой деструктивности вы говорите, если осуществляется копирование блоков, которое по определению сохраняет источник?

[drBatty]

О какой деструктивности вы говорите

о ресайзе.

я спорил с этим заключением:

время изменения размера раздела "вправо" (ещё не факт, что это требуется, ибо автор хочет, цитирую, "зеркальную копию") - это время изменения нескольких чисел в заголовке ФС и таблице разделов - несколько секунд от силы.

Если хотите продолжить спор, просите модератора отрезать его в другую тему.

[Rootlexx]

о ресайзе.

Ну-ну.

Вам нужен RO доступ к источнику, и потому этому источнику ничего не угрожает

дык у вас в процессе ВСЕ данные. А у нас -- только копии данных.

Расскажите, как "ресайз" назначения может быть деструктивным для источника, и как в нём принимают участие "ВСЕ данные".

[Rootlexx]

Вот вам загадка: как mkfs умудряется создать файловую систему ext4 размером 100 ГБ за 10 секунд

всё очень просто: для создания пустой ФС нужно просто создать место для 100500 инодов. Т.е. сделать несколько десятков блоков с ними (ЕМНИП они по 32768 штук в блоке). Но если у вас _уже_ есть 100500 файлов, то задача _существенно_ осложняется

Добавляются несколько групп блоков, с которыми ассоциируются новые таблицы inode. То же самое происходит и при создании ФС. При использовании "ленивой" инициализации время выполнения данной операции в сравнении с временем копирования данных ничтожно.

Если по вашему EXT4 проста

Не приписывайте мне ваши фантазии.

[drBatty]

Расскажите, как "ресайз" назначения может быть деструктивным для источника

никак. А кто предупредил, что нужно _обязательно_ сохранить источник? Вы этого не сделали.

и как в нём принимают участие "ВСЕ данные".

а можно подумать, не все? Иноды все участвуют, а файл без инодов === бесполезная груда мусора.

Добавляются несколько групп блоков, с которыми ассоциируются новые таблицы inode. То же самое происходит и при создании ФС.

а вы уверены, что достаточно "просто добавить"? А я не уверен.

Не приписывайте мне свои фантазии.

это у вас фантазии, связанные с "несколькими числами ФС". На самом деле, параметры создания ФС достаточно сильно и от многого зависят, в т.ч. и от размера. Если вы думаете, что сложением двух ФС вы получите вдвое большую -- вы ошибаетесь. Даже редактирование "пары чисел" вам не поможет. Если-бы речь шла о небольшом изменении, то я бы может и не спорил, но мы не знаем, что именно задумал ТС, потому не можем оценивать, насколько это фатально, и насколько долго.

[Rootlexx]

А кто предупредил, что нужно _обязательно_ сохранить источник? Вы этого не сделали.

Как будто вы - сделали:

1. создать на большом диске разделы и ФС
2. скопировать таром (сжимать в stdout, и сразу разжимать из stdin)
3. поправить загрузчик.

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

а вы уверены, что достаточно "просто добавить"? А я не уверен.

Почитайте документацию.

Если вы думаете, что сложением двух ФС вы получите вдвое большую

И опять:

Не приписывайте мне ваши фантазии.

Даже редактирование "пары чисел" вам не поможет. Если-бы речь шла о небольшом изменении, то я бы может и не спорил

Похоже, у нас недопонимание на почве "пары чисел".
Во-первых, я написал "нескольких".
Во-вторых, это не значит, что их можно пересчитать по пальцам одной руки.
В-третьих, изменения действительно невелики. Если хотите, можете провести эксперимент: создайте образ, создайте ФС на нём с заведомо меньшим размером, а потом измените её размер через strace и посчитайте количество вызовов lseek и write.
Я категорически не понимаю, почему использование детерминированной программы resize*fs вы считаете потенциально опасным, а использование tar, mkfs для создания ФС и драйвера для записи в неё - нет. Любая операция с ФС, подразумевающая её изменение, потенциально деструктивна, но вероятность этого не стоит разведения споров на полстраницы.

[Rootlexx]

1. создать на большом диске разделы и ФС
2. скопировать таром (сжимать в stdout, и сразу разжимать из stdin)
3. поправить загрузчик.

И да, перечисленных в вашей инструкции этапов недостаточно. Необходимо ещё подправить конфигурационные файлы, например, в Debian это как минимум /etc/fstab и /etc/initramfs-tools/conf.d/resume, а полный список я даже затрудняюсь перечислить. Так что предложенный вами способ не так прост, особенно для новичка.

[drBatty]

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

я по себе сужу. Я помнится раньше тоже думал, что расширить ФС "легко и быстро". Не получилось.

Почитайте документацию.

читал.

Я категорически не понимаю, почему использование детерминированной программы resize*fs вы считаете потенциально опасным, а использование tar, mkfs для создания ФС и драйвера для записи в неё - нет. Любая операция с ФС, подразумевающая её изменение, потенциально деструктивна, но вероятность этого не стоит разведения споров на полстраницы.

потому-что если у меня с первого раза не получилось растарить, получится во второй. А вот ресайз таким свойством сам по себе НЕ обладает.

И да, перечисленных в вашей инструкции этапов недостаточно. Необходимо ещё подправить конфигурационные файлы, например, в Debian это как минимум /etc/fstab и /etc/initramfs-tools/conf.d/resume

это ИМХО тоже "настройка загрузчика". Входит в п3.

[Rootlexx]

Я помнится раньше тоже думал, что расширить ФС "легко и быстро". Не получилось.

Ясно, негативный опыт. Что за ФС, и какие были проблемы?

потому-что если у меня с первого раза не получилось растарить, получится во второй. А вот ресайз таким свойством сам по себе НЕ обладает.

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

это ИМХО тоже "настройка загрузчика". Входит в п3.

Для этого нужно заранее знать, что необходимо отредактировать. И если fstab приходит на ум сразу же (и то не факт, что всем), то о существовании второго из перечисленных мной файлов известно далеко не каждому. И кто знает, что ещё может понадобиться подправить.
Более того, результат простой упаковки tar может быть некорректным. Например, в архив могут попасть не все жёсткие ссылки на некоторый файл, для предотвращения чего следует использовать опцию -l.
И даже это не спасёт, если присутствуют также разделы с другими ФС и ОС, например, Windows.
Таким образом, для правильного переноса всех данных и получения работоспособной копии системы требуется выполнение предварительных условий, а также наличие таких знаний, обладающий которыми и так будет в курсе, как проделать такую операцию, и не станет задавать подобных вопросов; и уж тем более нельзя рассчитывать на это в разделе "Вопрос новичка".
В результате использование dd и gparted, пусть и не всегда являясь оптимальным решением, на порядок проще.

[drBatty]

сно, негативный опыт. Что за ФС, и какие были проблемы?

ntfs,ext3. Ну с первой понятно всё, но вот вторая меня несколько разочаровала. Хотя подумав, я понял, что тут ничего удивительного нет. Проблема со временем, которое немалое. И, ИМХО, структура после ресайза _очень_ не оптимальная.. После mkfs+tar она _заметно_ быстрее. Возможно мои объяснения и не правильные, но я таки не теоретик. Я просто пытаюсь объяснить увиденное.

В результате использование dd и gparted, пусть и не всегда являясь оптимальным решением, на порядок проще.

"проще" понятие субъективное. И потому не буду спорить. Ещё раз повторю, что я спорил лишь с тем, что ваш метод _может_ быть опасен для данных, и об этом _нужно_ предупреждать. Ну а всякие fstab это не так критично, всегда можно вернуться и исправить. В вашем случае dd делает РАБОЧУЮ версию неправильного размера. Потому есть шанс, что возвращаться уже некуда. Мой способ делает либо рабочую копию нужного размера, либо НЕ рабочую, которую можно исправить из рабочей, причём недеструктивно для данных(если написать что-то не то в /etc/fstab система просто не загрузится)

[yamah]

Что-то я вообще не врубился, в чем спор...
Особенно мне непонятно чем отправка в tar с моментальной распаковкой лучше rsync или совсем простой cp?

У метода с dd точно есть несколько недостатков:
1. тупо копируется и "свободное место" на разделе. А точнее: не факт, что там совсем пусто, а не остатки старых удаленных файлов;
2. Нельзя таким образом скопировать данные в другую ФС.

[drBatty]

Особенно мне непонятно чем отправка в tar с моментальной распаковкой лучше rsync или совсем простой cp?

для каждого случая оптимален свой инструмент.

1. cp самый простой инструмент, копирует все файлы не глядя, при этом возможны проблемы с симлинками и правами(если забыть --preserve=all). К тому-же cp не умеет сжимать. Ну и ещё cp не умеет по ssh и вообще никак, кроме как в пределах локалхоста.

2. tar умеет сжатие, потому позволяет часто копировать быстрее (если скорость сжатия больше скорости передачи). Ещё tar позволяет сразу сделать бекап. Также tar позволяет сразу порезать архив на куски, если вы переносите флоппинетом (и так бывает. На флешках конечно). Ну и вообще поток tar'а можно отправить куда угодно.

3. rsync это отличный выбор для быстрой синхронизации, но копировать с чистого листа получается намного хуже, чем первыми двумя способами. Ну и её надо ставить дополнительно на оба сервера (в отличие от tar&cp, которые практически всегда уже есть)

[yamah]

Ну и ещё cp не умеет по ssh

scp, не?

Ещё tar позволяет сразу сделать бекап.

Это понятно.
Может я уже где-то туплю, но, по-моему, отправка в поток и сразу же распаковка из потока не создаст файл.
Да и в пределах одного хоста бесмысленно, вроде.

[drBatty]

scp, не?

не. Её возможности копирования атрибутов ограничены -p. Я вот даже не знаю, осилит-ли она полностью точно скопировать всё дерево каталогов, со всеми симлинками, устройствами, и прочим. А вот tar может, я проверял неоднократно.

Может я уже где-то туплю, но, по-моему, отправка в поток и сразу же распаковка из потока не создаст файл.

простите, да.

есть два варианта:
1. нужен файл
2. не нужен файл
tar работает в любом случае, (s)cp только в одном. Откуда вывод.

[yamah]

есть два варианта:
1. нужен файл
2. не нужен файл

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

Её возможности копирования атрибутов ограничены

А?! Да. Уже сталкивался, что права не сохраняются.