Pull to refresh

Comments 13

Очень полезно — спасибо! Вообще не знал что есть две разные утилиты с почти одинаковыми именами.
Я сам удивился, когда узнал. А уж когда выснилось, что они обе активно развиваются — любопытству моему не было предела. Приятно, что вопрос интересен не только мне одному :).
Для копирования по 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 user@my.host "cat > random_data"
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»
To, что ddrescue не умеет отдавать данные в stdout не design failure, а осознанное решение, принятое из-за того, что передача данных в pipe несовместима с чтением
данных с устройства в несколько проходов.
— это уже не UNIX way, правильно это делается через
dd if=file | bzip2 | ssh 'cat >file.bz2'

Не всё, что UNIX way правильно и наоборот. Но на всякий случай отмечу, что UNIX way dd_rescue тоже умеет, то есть его спокойно можно встроить в конвейр. Однако если мы знаем какие данные жмём это позволяет сжимать более эффективно, а также внедрить фичи недоступные при использовании инструментов общего назначения. Что собственно и делает dd_rescue через плагинный механизм.
Да, ошибочка. ddrescue так использовать не получится, только dd.
GNU ddrescue не умеет отдавать данные в пайп. А dd_rescue вполне себе может.
Когда я охарактеризовал dd_rescue как улучшенный вариан dd я имел в виду, прежде всего его способность копировать повреждённые диски :). dd действительно умеет достаточно много и, в том числе, как показано ниже — отдавать вывод в stdout.

Но то, что вы тут показали лично мне любопытно. Скажите, команда dd if=/dev/urandom of=./pipe передаст управление дальше и будет скармливать новые данные в пайп только по мере их вычитки cat? Или я неправильно всё понял?
Тут я немного упростил. ssh я запускал в отдельном шелле. Но можно для dd поставить в конце & — тогда команда уйдет в бэкграунд и можно в том же шелле запустить ssh.
А вот насчет данных — да, будет писать по мере вычитки.
О как! Я не знал, что так можно, спасибо.
«Мера вычитки», насколько мне известно, зависит от опций bs/ibs/obs: они указывают, с какими блоками работать/какими блоками читать/какими блоками писать («какими блоками» = какого размера блоки использовать).
А что, контроллеры современных жёстких дисков ещё дают какое-то подобие низкоуровневого доступа? Там и геометрия уже давно «виртуальная», да и всё остальное наверное тоже.
Таки дают. Ну то есть можно попросить вернуть определённый кусок диска в 512 байт. И диск представлен в линуксе блочным устройством с линейной адресацией.
Sign up to leave a comment.

Articles