dd_rescue vs GNU ddrescue: зачем нужен клон, когда есть оригинал

[UncleAndy]

Очень полезно — спасибо! Вообще не знал что есть две разные утилиты с почти одинаковыми именами.

[poxvuibr]

Я сам удивился, когда узнал. А уж когда выснилось, что они обе активно развиваются — любопытству моему не было предела. Приятно, что вопрос интересен не только мне одному :).

[BlackRaven86]

Для копирования по ssh при помощи dd можно использовать специальный тип файла — FIFO.

[nekit@localhost fifo_test]$ mkfifo pipe
[nekit@localhost fifo_test]$ ls -l
итого 0
prw-r--r-- 1 nekit nekit 0 Сен 16 13:28 pipe|
[nekit@localhost fifo_test]$ dd if=/dev/urandom of=./pipe
[nekit@localhost fifo_test]$ cat pipe | ssh [e-mail] "cat > random_data"

[zuborg]

dd и так отлично умеет отдавать в stdout:

# man dd | grep -A 1 of=FILE
       of=FILE
              write to FILE instead of stdout

А вот если этого не умеет ddrescue — то это уже design failure

Кроме там есть плагинный механизм с помощью которого поддерживается сжатие и разжатие на лету

— это уже не UNIX way, правильно это делается через

dd if=file | bzip2 | ssh 'cat >file.bz2'

А сжимать трафик и сам ssh умеет — «ssh -C»

[poxvuibr]

To, что ddrescue не умеет отдавать данные в stdout не design failure, а осознанное решение, принятое из-за того, что передача данных в pipe несовместима с чтением
данных с устройства в несколько проходов.

— это уже не UNIX way, правильно это делается через
dd if=file | bzip2 | ssh 'cat >file.bz2'

Не всё, что UNIX way правильно и наоборот. Но на всякий случай отмечу, что UNIX way dd_rescue тоже умеет, то есть его спокойно можно встроить в конвейр. Однако если мы знаем какие данные жмём это позволяет сжимать более эффективно, а также внедрить фичи недоступные при использовании инструментов общего назначения. Что собственно и делает dd_rescue через плагинный механизм.

[BlackRaven86]

Да, ошибочка. ddrescue так использовать не получится, только dd.

[poxvuibr]

GNU ddrescue не умеет отдавать данные в пайп. А dd_rescue вполне себе может.

[poxvuibr]

Когда я охарактеризовал dd_rescue как улучшенный вариан dd я имел в виду, прежде всего его способность копировать повреждённые диски :). dd действительно умеет достаточно много и, в том числе, как показано ниже — отдавать вывод в stdout.

Но то, что вы тут показали лично мне любопытно. Скажите, команда dd if=/dev/urandom of=./pipe передаст управление дальше и будет скармливать новые данные в пайп только по мере их вычитки cat? Или я неправильно всё понял?

[BlackRaven86]

Тут я немного упростил. ssh я запускал в отдельном шелле. Но можно для dd поставить в конце & — тогда команда уйдет в бэкграунд и можно в том же шелле запустить ssh.
А вот насчет данных — да, будет писать по мере вычитки.

[poxvuibr]

О как! Я не знал, что так можно, спасибо.

[ZyXI]

«Мера вычитки», насколько мне известно, зависит от опций bs/ibs/obs: они указывают, с какими блоками работать/какими блоками читать/какими блоками писать («какими блоками» = какого размера блоки использовать).

[Beholder]

А что, контроллеры современных жёстких дисков ещё дают какое-то подобие низкоуровневого доступа? Там и геометрия уже давно «виртуальная», да и всё остальное наверное тоже.

[poxvuibr]

Таки дают. Ну то есть можно попросить вернуть определённый кусок диска в 512 байт. И диск представлен в линуксе блочным устройством с линейной адресацией.