|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 21 Jul 2002 23:08:00
To : Ramazan Ja-Far
Subject : Re: Copy Linux -> new hdd
--------------------------------------------------------------------------------
Hi, Ramazan!
>>>>> "RJ" == Ramazan Ja-Far <ramazanjf@svitonline.com> writes:
>> ясно, man dump; man restore читать не хотим, хотим пофлеймить. Дело
>> хозяйское. Про то, что файл с дампомо создавать как-бы не нужно, для
>> этого есть пайп, догадаться тоже сложно.
RJ> Hет, просто лень писать dump -0 -f - / | restore -r -f -
RJ> // И, кстати, какие там будут параметры в BSD :)? Или в Solaris?
>> Какой там, мы же пытаемся доказать что cp -a рулез форевер...
RJ> Ты не привёл убедительных доводов в пользу dump/restore.
так нада было сразу српосить аргументов, и сказать какие именно аргуенты
ты считаешь убедительными.
Я, со своей стороны, никого нив чем убеждать не пытался.
Высказалварианты, котоыре _Я_ СЧИТАЮ ПРАВИЛЬHЫМИ.
Я не спорил что есть другие приемлимые в некоторых ситуациях варианты
решения. И даже подтвердил, что сам пользую "другие".
К чему флейм-то с наездами?
RJ> Вот что я отвечу _аргументированно_, и что не сказал ты сам:
RJ> dump/restore _нужен_, если используются дополнительные ext2 атрибуты
RJ> (смотри man chattr). Или если ситема - не Linux (как отметил Victor
RJ> Wagner).
dump/restore более универсальное и переносимое средсво. Потому что оно
предназначено для сохранения и восстановления файловых систем.
А вот у cp предназначние совсем другое. Хотя иногда их возможности
пеерсекаются. Что может быть более убедительным, чем man dump?
Hужно было зичитать его сюда?
RJ> А по скорости, я только что закончил замерять копирование
RJ> 3.8 гигабайтов при помощи dump/restore и cp -ax
RJ> Пока только в пределах одного винта - с ext3 раздела на ext3 раздел.
RJ> Утверждение в конце письма про копирование с одного винта на другой я
RJ> проверю попозже. Можешь проверить сам.
RJ> cd /mnt/x && time dump -0 f - / | restore -r -f - 24:02
RJ> rm -rf /mnt/x/*
RJ> time cp -ax / /mnt/x 20:54
RJ> Как видишь, cp на 3 минуты быстрее, т.е. на 10%
мндэ. И что это показывает? Что кешатор хороший. Что хооршо
оптимизируется конкурентный доступ к одному диску на чтение/запись.
Утверждение было совсем про другое.
Раз уж ты взялся замеры делать - попробуй несколько файловых систем
копировать. Только с винта на винт. Одновременно. /, /usr, /var
>> dump/restore _я_считаю_ БОЛЕЕ ПРАВИЛЬHЫМ СПОСОБОМ.
RJ> Просто аргументов ты не привёл.
я указал место где их может прочесть каждый умеющий читать.
>> dump/restore работают на уровне файловой системы.
RJ> :) Теория не всегда подтверждается на практике...
какая теория? dump по определению знает о файловой системе БОЛЬШЕ, чем
cp. Просто by design.
>> у меня вот еще есть такой рецептик "в заначке":
>>======
>> From: Alex Korchmar <Alex.Korchmar@f28.n5020.z2.fidonet.org>
>>...
>>а это у вас, батенька, от неумения пользоваться тем, для чего, собственно,
>>юниксная среда предназначена.
>>tar -cSlpv / | tar -xpv -C /mount/где-там
RJ> Кстати, tar не сохраняет ext2 атрибуты (chattr). Так что он вряд-ли в
RJ> чём-то лучше cp -ax для копирования...
два независимых процесса. Один читает с одно диска, другой пишет на
другой. Паралельно.
Замеры скорости оставлю каждому желающему в качесве "развлекалочки".
>> я уж не говорю про совсем очевидную вещь - запуская два процесса связаных
>> через пайп, мы более эфективно нагружаем дисковую подсистему. Потмоу что
>> пока один dump/tar с одного винта читает, второе restore/tar на другой
>> пишет. ОДHОВРЕМЕHHО. В отличии от cp -a, который делает все сам.
RJ> Как я написал выше, тут нужно сделать бенчмарк. У меня есть два
RJ> винта, но второй медленнее. Поэтому описанный эффект может быть
RJ> незаметен.
Медленость второго винта не сильно повлияет. Тест больше
характеристический. Досттаочно зафиксировать сам факт.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
