dd?

dd явно не в тему.

Странно, сам rsync использую регулярно, все в порядке. Через ssh.

Как вариант - tar'ом сплющить в один файл, если всем именно из-за количества крышу сносит.

А почему dd не в тему? Берём логический том LVM, на котором лежит исходная файлуха, и копируем в файл, как это пытался сделать ТС. Потом либо монтируем тот файл как устройство, либо уже заливаем в раздел на другом диске, при желании увеличивая размер.

И, между прочим, почему не использовать более простое cp -a?

Первое что попробовал - «rsync -aH». Он запустил зачем-то два процесса rsync, и в течение минут 15-20 каждый из них съел по 3ГБ оперативки, после чего память кончилась, и начался пилёж свапа.

Основная задача rsync - это не копирование, а синхронизация. А для этого перед началом переноса данных он должен получить список файлов с источника, чтобы определить что изменилось, а что нет. И весь список файлов он хранит в оперативной памяти. Так что скорее всего просто у тебя было очень много файлов =).

Вопрос: чем можно выполнить такое копирование, затратив на всю операцию не более 6-8 часов? Сеть гигабитная, на требуемый объем хватит с большим запасом, но только если копирующий софт будет не тупить, а хотя-бы худо-бедно переписывать данные.

Я как-то переносил полностью систему (~150GB) с одного компьютера на другой по сети при помощи tar и netcat. Примерно так:

# Откуда копируем
tar vcjp / | nc $DESTINATION $DESTINATION_PORT

# Куда копируем
nc -l $DESTINATION_PORT | tar vxjp

Не очень внимательно прочитал

Задача стояла такая: на большом томе (~3ТБ, LVM, ext3) записано около 200ГБ данных. Требуется слить всё 1:1 в другое место. Для этого был создан target раздел размером 400ГБ (если важно, то даже не раздел, а файл на другом сервере, отформатированный в ext3 и примонтированный через loop). Никаких виртуальных файлов (типа procfs) в исходном разделе нет, есть только файлы, hard- и sym-линки.

Тогда на стороне сервера вообще не надо ничего распаковывать - можно так и оставить tar.bz2.

Только что идея в голову пришла, как думаете - сработает?

Попробовать ужать том с данными до, скажем, 250 гиг, а потом - dd. Плюс в том, что можно в два этапа делать (если по времени укладываться не будет), сначала ужать и работать на ужатой, а в следующий раз как будет «окно» - dd. Но насколько надежна процедура ужимания? Не будет ли она так же тупить? Какова вероятность грохнуть вообще всю файловую систему в случае какого-либо сбоя? (Об электричестве можно не беспокоиться, но оно ж может и само)

А почему dd не в тему?

А сколько данных придется слить при этом? 3Тб?

> Тогда на стороне сервера вообще не надо ничего распаковывать

Надо-надо. Но это уже другая история. Попробовал tar-ом (пока на живой системе) - вроде архивирует, не тупит. Получается, запаковать tar-ом, потом им же распаковать в другое место — эффективнее, чем просто скопировать. Чудны дела.

cp -vax?

Я по 100-200Гб по сети просто копировал при помощи mc :) Главное, не подключаться по sshfs, а то она иногда подвисает.

Получается, запаковать tar-ом, потом им же распаковать в другое место — эффективнее, чем просто скопировать.

Как так «просто скопировать»? Просто скопировать с одной системы на другую по сети нельзя, т.к. требуется как-то преодолеть сеть =). Можно примонтировать вторую систему по nfs и скопировать обычным cp. Но если nfs не настроен, то tar + netcat проще и быстрее.

Вот кстати про rsync и память (из man'a):

              Beginning  with  rsync 3.0.0, the recursive algorithm used is now an incremental scan that uses much less memory than before and begins the transfer
              after the scanning of the first few directories have been completed.  This incremental scan only affects  our  recursion  algorithm,  and  does  not
              change a non-recursive transfer.  It is also only possible when both ends of the transfer are at least version 3.0.0.

А ведь и правда

Блин, ну почему же мне не проверить было сразу?...

Я знал, что cp умеет линки правильно копировать, но почему-то считал, что только в пределах одной файловой системы (или раньше так было). Сейчас попробовал - сохраняет и при перемещениях тоже. Буду пользовать...

> записано около 200ГБ данных. Требуется слить всё 1:1 в другое место.

Вопрос: чем можно выполнить такое копирование, затратив на всю операцию не более 6-8 часов?

Я с вас фигею, луноходы.

Гавно вопрос — «cp -av /source /target».
200ГБ по гигабитной сетке будут копироваться со скоростью ~ 50МБ/с ~ 1 час 10 минут.

Кыш отсюда. Топик прочти сначала, а потом сри своими каментами.

>перенос данных (винт освободить
Т.е. не ОСи с бут секторами и т.п., а просто перенос файлов.
cp -Rv чем не не устроил или mv?

Он запустил зачем-то два процесса rsync

Let's guess... double core CPU?

не более 6-8 часов

уу. ./me забил торрентами 400 Gb из 1000Gb за один вечер со сто мегабитной сеткой. зЫмний вечер.

dump

Ты бы catэ к этому делу в сообщники записал.
sudo cat /dev/sda >>/dev/sdb1

я конечно вендузятник, но спрошу:

а чем mc то неугодил ?! О_О

Зажуй червячка.

Нет ты!

> cp -Rv чем не не устроил или mv?

Я думал, что CP не скопирует правильно hard-линки. Оказалось, неправильно думал. Сейчас им и копирую. Но медленно получается: 1,5-2,5 мегабайта в секунду. Думаю, из-за особенностей. Файлы мелкие и много, в среднем где-то 40 килобайт на файл, зато их - миллионы. Хотя есть ощущение, что что-то здесь не так. 2 МБ/сек ну уж слишком медленно даже для такого расклада.

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

Он запустил зачем-то два процесса rsync

Let's guess... double core CPU?

Мимо. Quad. Должно было быть четыре?

sudo cat /dev/sda >>/dev/sdb1

Это стёб такой? А чего делать, если sdb1 меньше, чем sda1? Если бы можно было, давно сделал бы dd и не морочил бы голову.

>Но медленно получается:

cp -a с винта на винт медленно по с равнению с cp так что не удивительно.

>sdb1 меньше, чем sda1

Я писал буковки в [telepath mode][/telepath mode]. И надо же. Угадал!

А насчёт медленно. ext3 - да, не победитель в гонке за крол^мелкими файлами. ext4 reiser(4) - what you like.

За стёб извиняюсь. Про особенности с хард линками не знал.

> (это писал я) Пока жду, посмотрим. Если не успеет до завтра, опять что-то надо будет думать.

Вот и не успело оно :-( Надо думать что-то более скоростное.

(это писал darkshvein) Я писал буковки в [telepath mode][/telepath mode]. И надо же. Угадал!

Нет, буковки, конечно, другие. У меня тоже абстрактное мышление имеется :-)

А насчёт медленно. ext3 - да, не победитель в гонке за крол^мелкими файлами. ext4 reiser(4) - what you like

Насколько я читал про reiser - у него хорошо получается работа с совсем мелкими файлами (меньше размера блока). У меня же всё-таки большинство файлов размером 10-40 килобайт. Будет ли существенно быстрее, чем ext3? Да и вообще, насколько я слышал, разработку этой файловой системы никто не подхватил после известных событий с её автором, т.е. что с ней будет дальше не вполне понятно.

насколько понимаю, в данном случае, копирование упирается в производительность дисков. а если поставить простое удаление всего вашего архива(rm -rf) то вообще море времени займет.

>Будет ли существенно быстрее, чем ext3?
Доо.

Холиворить не буду. Лишь поправлю.

разработку этой файловой системы никто не подхватил после известных событий с её автором

это про reiserfs4. reiser давно уже в ядре и поддерживается. Хотя, можж ещё потестить xfs. Там дефраг есть.

А если чем-нибудь типа fsarchiver?

Если ext3 и много мелких файлов - то dump/restore должно быть быстрее, т.к. напрямую читает иноды.

Первые пол-часа елозил по диску dump, читая по 40 мегабайт в секунду. Куда он девал прочитанное - непонятно, ибо в оперативку бы явно не влезло, ну да ладно.

Все правильно. dump работает в несколько проходов:

  DUMP: Mapping (Pass I) [regular files]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Dumping (Pass III) [directories]
  DUMP: Dumping (Pass IV) [regular files]

Потом за работу принялся restore. Этот сожрал одно из четырёх процессорных ядер целиком, и за полтора часа интенсивной «работы» создал в target пару десятков каталогов и ни одного файла. Я понял, что в обозримом будущем результата тоже не будет, и вернул всё назал.

А вот это уже пошел дамп. Сначала читаются директории, потом - файлы. Видно, у тебя их мноого. Повторюсь, dump/restore напрямую читает иноды -> выгодно использовать при большом количестве файлов.

> И весь список файлов он хранит в оперативной памяти. Так что скорее всего просто у тебя было очень много файлов =).

Возможно оперативка кончилась/была на исходе, и система долго шуршала свопом.

Я промазал темой, извиняюсь