Перенос системы, что лучше, cp, tar, cpio, rsync?

Хоть на новом-то диске у тебя хватит ума LVM заюзать?

А кто сказал, что его не было?

Хоть на новом-то диске у тебя хватит ума LVM заюзать?

Желание использовать LVM происходит скорее от отсутствия ума и понимания как он (не)работает, чем от обратного. Ты бы ещё ext4 предложил использовать в проде, клоун.

Для копирования большого количества файлов cp не подходит совсем. Rsync, наверное, самый универсальный вариант.

dd и resize2fs — по сравнению с остальными плохо, потому что времени не выиграешь, а фрагментация ФС останется.

rsync — если можно воткнуть в одну систему два диска.

tar — если переносишь через промежуточный носитель.

В общем, никакого rocket science тут нет.

Что плохого в LVM?

Впрочем честно говоря, не вижу от него особой пользы, resize2fs в любом случае нужен, если ресайзить, хоть с lvm, хоть без него, так что лёгкости какой-то ресайза не вижу. Но вроде штука полезная, если нужно скажем иметь raid1 на несколько разделов и не хочется отдельный raid для каждого делать.

А ext4 чем плоха? Она вроде давным-давно как стабильна. Вот насчёт btrfs есть сомнения.

rsync — если можно воткнуть в одну систему два диска.

Обычно втыкаю диск через коробочку в USB.

Так чем rsync лучше просто cp или cpio?

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

(Если прервётся копирование, rsync найдёт, где остановился, а cp без ухищрений начнёт заново.)

Ну так осиль vgextend/pvmove/vgreduce и не занимай время достойных людей.

resize2fs в любом случае нужен, если ресайзить, хоть с lvm, хоть без него

lvresize -r

Что плохого в LVM?

Имплементация.

А ext4 чем плоха? Она вроде давным-давно как стабильна.

Архитектурой плоха. Для дисков малого размера и с низким i/o она подходит (например, в телефоне или на флешке), но на рабочую станцию и, тем более, на сервер она не подходит совершенно.

Вот насчёт btrfs есть сомнения.

btrfs (пока) никто не предлагал. Я бы точно не предложил.

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

Хотя системные вызовы одни и те же, но cp вызывает их синхронно, в отличие от rsync, который пока один диск занят записью, успевает на другом полезной работы поделать.

Метанимус доставляет.

Для дисков малого размера и с низким i/o она подходит (например, в телефоне или на флешке), но на рабочую станцию и, тем более, на сервер она не подходит совершенно.

аргументируй если не сложно, пожалуйста
Самому интересна тема

rsync — если можно воткнуть в одну систему два диска.

tar — если переносишь через промежуточный носитель.

facepalm.jpg

rsync не имеет смысла в пределах одной машины; tar c | tar x не нуждаются в промежуточном носителе.

аналог rsync --delete в пределах одной машины подскажете?

Я думал, cp использует sendfile(). А оно там какую-то магию с sparse-файлами совершает.

rsync не имеет смысла в пределах одной машины

Ещё как имеет.

tar c | tar x не нуждаются в промежуточном носителе

И зачем же в этом случае использовать tar, если работа ведётся не по сети?

аргументируй если не сложно, пожалуйста

А какие именно нужны аргументы? У тебя никогда inodes не кончались на Ext{2,3}? У тебя не было проблем с доступом к большому количеству файлов? То, что даже до тормозов вроде RH дошло, что с Ext они далеко не уедут и теперь по дефолту в RHEL7 предлагается XFS в качестве аргумента пойдёт? Успех Ext* вообще обусловлен нетехническими причинами. Просто когда-то она была единственным выбором в качестве своей файловой системы для Linux, да так с тех пор и повелось.

rsync не имеет смысла в пределах одной машины

Ещё как имеет.

Ты забыл перечислить смыслы.

И зачем же в этом случае использовать tar

Ненене, это ты должен объяснять, зачем в данном случае использовать rsync (и сеть здесь вообще не причем).

если работа ведётся не по сети?

Просто для протокола: в конвейер между tar можно вставить и прброс по сети, и tar будет эффективнее rsync (для данного юзкейса, естественно, а то душевнобольной выше по треду уже спрашивает про --delete).

lvresize -r

Ну parted так может с обычными разделами MBR или GPT и что?

Имплементация.

Архитектурой плоха.

И чем она плоха?

но на рабочую станцию и, тем более, на сервер она не подходит совершенно.

А что подходит? И почему тогда в дистрах во всех ext4 по дефолту?

Ну ладно, не во всех. А у xfs вроде проблемы с ресайзом и нет fsck полноценной?

Если иноды кончаются — ССЗБ, сделал так мало инодов, и это было про ext{2,3}, а не 4

Ну parted так может с обычными разделами MBR или GPT и что?

Без размонтирования и без двигания соседнего раздела? Хочу такой parted.

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

А что lvm умеет с любой ФС? Это же ещё файловая система без размонтирования должна ресайзиться.

Соседний раздел можно не двигать, если место есть перед ним.

В любом случае, на домашнем компе выключить и ресайзнуть всё с livecd не проблема и проще чем извращаться с lvm

Я не думаю

Мы живём в свободной стране, твоё право.

Ты бы ещё ext4 предложил использовать в проде, клоун.

А что ты предлагаешь? XFS?

Имплементация.
Архитектурой плоха.
И чем она плоха?

Ты действительно ждёшь, что я тебе в комменте на ЛОРе кратенько распишу то, о чём люди на защитах рассказывают? Нет, вот действительно?

но на рабочую станцию и, тем более, на сервер она не подходит совершенно.
А что подходит?

XFS подходит. ZVOL подходит. Ext{2,3,4} и LVM{,2} — не подходят.

И почему тогда в дистрах во всех ext4 по дефолту?

Это исключительно по традиции. Когда-то Ext была единственной файловой системой. Потом её Реми Кард с учётом тогдашних реалий переписал и назвал Ext2. И вот в таком виде Ext попала как ФС по умолчанию во все(?) дистрибутивы. И это действительно был неплохой выбор и с точки зрения лицензионной чистоты, и для затыкания ртов хейтерам, которые не применули бы язвить на тему отсутствия собственной ФС в «студенческой поделке». Казалось бы после портирования в Линукс в начале 2000х SGIшной XFS, уже точно ничто не мешало забыть Ext и оставить в качестве легаси, но ситуация повернулась опять нетехнической стороной: все привыкли видеть Ext ФС по умолчанию, а те три с половиной админа, которых она не устраивала умели при установке выбрать другую. К тому же, в ядро XFS попала в 2002 (в 2.4.x), а в GRUB поддержка появилась только в 2004 или окло того. LILO поддерживало загрузку с XFS-разделов только при условии установки в MBR (что было не всегда возможно по разным причинам).

Ну ладно, не во всех. А у xfs вроде проблемы с ресайзом и нет fsck полноценной?

Ресайз у XFS возможен в сторону увеличения и должен производиться наживую, на примонтированной системе. FSCK там вообще не нужен, а штатный режим завершения работы у XFS — завершение процесса, хоть посылкой SIGKILL. Восстановление (recovery) ФС происходит в момент монтирования, но тем не менее по многочисленным просьбам fsck.xfs существует и его man честно признаётся: «fsck.xfs - do nothing, successfully». Для починки ФС, которым во внутренние структуры написали немного /dev/random есть xfs_repair. За 10 лет использования XFS я им вынужден был воспользоваться 1 раз, поэтому если тебе нужна консультация по нему, я помочь не смогу ничем, кроме сочувствия и парного чтения манов вслух.

Если иноды кончаются — ССЗБ, сделал так мало инодов, и это было про ext{2,3}, а не 4

Наличие фиксированного количества инодов — вот, где настоящее ССЗБ. Не существует способа точно предсказать оптимальное количество инодов в общем случае, именно отсюда растут ноги у этих изменений в etx4. Кроме того, переключение на ext4 уже существующих разделов проблему не решает. Но надо сказать, что копья ломать имеет смысл только если мы говорим о доступе к большому количеству файлов разного размера. На марафонских забегах по последовательному чтению больших файлов Ext4, если я не путаю, продолжает лидировать и не собирается переставать это делать.

У тебя никогда inodes не кончались на Ext{2,3}?

неа, но были общие тормоза
На ext4 вроде не замечал

То, что даже до тормозов вроде RH дошло, что с Ext они далеко не уедут и теперь по дефолту в RHEL7 предлагается XFS в качестве аргумента пойдёт?

нагуглил xfs срач, далеко ходить не надо:
XFS vs EXT4 на разделе в ~ 5000GB под CentOS 6.4/RHEL 6.4 x86-64
Там точно всё в порядке?

З.Ы. На серверах UFS2

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

тут dd лидирует. работа с метаданными 10^9 файлов — большой overhead. Если надо лить dd по сети, то зануление свободного места и сжатие помогут.

У тебя никогда inodes не кончались на Ext{2,3}?
неа, но были общие тормоза
На ext4 вроде не замечал

В ext4 не стесняясь (да и чего там стесняться?) взяли пару идей из XFS в том числе. И это явно пошло ей на пользу. Но по-моему немного поздновато: этот код уже написан, оттестирован и обезбажен в другом файле. Без прорывных идей это так же эффективно, как и воду в ступе толочь.

нагуглил xfs срач, далеко ходить не надо:
XFS vs EXT4 на разделе в ~ 5000GB под CentOS 6.4/RHEL 6.4 x86-64
Там точно всё в порядке?

Да, всё замечательно. 5 ТБ и сто тысяч файлов в сутки это же смешной объём. Но когда на ЛОРе срача не было?

З.Ы. На серверах UFS2

Сочувствую.

Сочувствую

себе посочувствуй, умник )

не нашел пруфцов за XFS помимо «ext4 гугно»

Так чем rsync лучше просто cp или cpio?

Всем, кроме потребления памяти. Асинхронный ввод/вывод, продолжение незавершённого копирования, чёрные списки, етц, етц, прочти же man rsync наконец.

Однозначно tar

tar | tar

Асинхронный ввод/вывод

Щито?

продолжение незавершённого копирования, чёрные списки

Зачем это в сабжевой задаче?

истории успеха rsync -av [exclude] [from] [to]:
* переносил систему на новый винт
* копировал систему на работающий удаленный сервер, с последующей перезагрузкой в новое окружение

а еще он умеет -e "ssh -p23321" и пр. remote shell, сжатие и еще кучу разных полезных параметров
ткчо rsync хватит всем ;)

Щито?

rsync запустит клиент и сервер прямо на локальной машение и будет читать-писать одновременно. Так понятно?

Зачем это в сабжевой задаче?

Когда электричество посреди процесса закончится, не придётся начинать сначала.

rsync запустит клиент и сервер прямо на локальной машение и будет читать-писать одновременно. Так понятно?

Это понятно (хотя это не асинхронность). Непонятно, чем это отличается от tar | tar, где чтение и запись тоже разнесены по разным процессам.

продолжение незавершённого копирования, чёрные списки

Зачем это в сабжевой задаче?

Когда электричество посреди процесса закончится, не придётся начинать сначала.

Черные списки зачем?

не нашел пруфцов за XFS помимо «ext4 гугно»

Так ты и не искал, поди, равно как и пруфов обратного :)

Но нет ничего проще, чем взять сервер из прода, посмотреть на паттерны нагрузки, написать хорошую симуляцию и проверить в лаборатории. Мы это делаем у себя каждый раз, когда кто-то предлагает всё поменять и по результатам даже иногда что-то действительно меняем. Технологический выбор это процесс, а не состояние. Его можно и нужно периодически пересматривать.

не нашел пруфцов за XFS помимо «ext4 гугно»

Первая ссылка в моём Гугле: похороникс.

во всех

Ни фига. openSUSE уже предлагает btrfs, RHEL/CentOS/Fedora уже упоминали.

Ни фига. openSUSE уже предлагает btrfs

По умолчанию или как опцию?

По умолчанию для /, а вот про /home и прочее уже не помню.

По умолчанию для /, а вот про /home и прочее уже не помню.

Смело. Кому-то стоило начать, почему бы и не им? Я надеюсь, это только на пользу btrfs пойдёт.

Синтетика.

http://alv.me/?p=5363

Там чувак правильно пишет про мифы о более вероятных потерях при некорректном завершении работы. В XFS нет такого понятия, как корректное/некорректное завершение. И я всё ещё недоумеваю, откуда взялся миф о том, что на большом количестве файлов малого размера XFS начинает как-то особенно тормозить.

Черные списки зачем?

Чтобы не тратить время на перенос ненужных вещей (кэши, временные файлы и т.п.). Когда у тебя лежит чёрный список для rdiff-backup, почему бы не воспользоваться?

откуда взялся миф о том, что на большом количестве файлов

Взялся отсюда

Metadata operations in XFS have historically been slower than with other file systems, resulting in, for example, poor performance with operations such as deletions of large numbers of files. However, a new XFS feature implemented by Dave Chinner and called delayed logging, available since version 2.6.39 of the Linux kernel mainline, is claimed to resolve this;[22] performance benchmarks done by the developer in 2010 revealed performance levels to be similar to ext4 at low thread counts, and superior at high thread counts.[23]

истории успеха rsync -av

Ага, hard links, accl, extended attributes в пролете.

Я всегда исп. dump/restore

ТС, а цель то какая — клонирование или миграция со старого диска на новый?

s/accl/ACL/