glibc нужно, чтобы в ОС была версия 2.29, а у меня есть одно приложение, которое требует максимум 2.27. Как решить, чтобы оба работали?

Ваша проблема, вероятно, не в вашем компьютере, как таковом, он, вероятно, в порядке. Но этот переходный слой USB-флэш имеет свой собственный процессор, который должен составить карту всех ваших записей, чтобы компенсировать то, что может быть на 90% неисправным чипом флэш-памяти, кто знает? Вы зальете ее, затем зальете свои буферы, затем зальете всю шину, и тогда вы застрянете - ведь именно там находится все ваше содержимое. Это может показаться неинтуитивным, но на самом деле вам нужна блокировка ввода-вывода - вам нужно позволить сверхсветовым скоростям задавать темп, а затем просто идти в ногу".

(О взломе микроконтроллеров FTL: http://www.bunniestudios.com/blog/?p=3554)

Все вышеперечисленные ответы должны работать, так что это скорее "я тоже!", чем что-либо еще: я был там, чувак. Я решил свои проблемы с помощью --bwlimit arg в rsync (2.5 Мб показались мне оптимальным вариантом для одного запуска без ошибок - если больше, я получал ошибки защиты от записи). rsync особенно подходил для моей цели, потому что я работал с целыми файловыми системами - то есть было много файлов - и простой запуск rsync во второй раз устранял все проблемы первого запуска (что было необходимо, когда я становился нетерпеливым и пытался разогнаться до 2,5 Мб).

Тем не менее, я полагаю, что это не совсем практично для одного файла. В вашем случае вы могли бы просто передать dd в режиме raw-write - таким образом вы можете обрабатывать любой вход, но только один целевой файл за раз (хотя этот единственный файл может быть целым блочным устройством, конечно).

## OBTAIN OPTIMAL IO VALUE FOR TARGET HOST DEV ##
## IT'S IMPORTANT THAT YOUR "bs" VALUE IS A MULTIPLE ##
## OF YOUR TARGET DEV'S SECTOR SIZE (USUALLY 512b) ##
% bs=$(blockdev --getoptio /local/target/dev)

## START LISTENING; PIPE OUT ON INPUT ##
% nc -l -p $PORT | lz4 |\ 
## PIPE THROUGH DECOMPRESSOR TO DD ## 
>    dd bs=$bs of=/mnt/local/target.file \
## AND BE SURE DD'S FLAGS DECLARE RAW IO ##
>        conv=fsync oflag=direct,sync,nocache

## OUR RECEIVER'S WAITING; DIAL REMOTE TO BEGIN ##
% ssh user@remote.host <<-REMOTECMD
## JUST REVERSED; NO RAW IO FLAGS NEEDED HERE, THOUGH ## 
>    dd if=/remote/source.file bs=$bs |\
>    lz4 -9 | nc local.target.domain $PORT
> REMOTECMD  

Вы можете обнаружить, что netcat немного быстрее, чем ssh для передачи данных, если попробуете. В любом случае, другие идеи уже были приняты, так почему бы и нет?

[EDIT]: Я заметил упоминания lftp, scp и ssh в другом сообщении и подумал, что мы говорим об удаленной копии. Локальная намного проще:

% bs=$(blockdev --getoptio /local/target/dev)
% dd if=/src/fi.le bs=$bs iflag=fullblock of=/tgt/fi.le \
>    conv=fsync oflag=direct,sync,nocache

[EDIT2]: Отдаю должное: только что заметил, что ptman опередил меня на пять часов в комментариях.

Определенно, вы можете настроить $bs на производительность здесь с помощью множителя - но некоторые файловые системы могут потребовать, чтобы он был кратен размеру секторов целевого фс, так что имейте это в виду.