Странное поведение метра прогресса SSH/SCP

Нет, это не делает насколько я знаю. Но можно всегда использовать mkdir -p и touch друг после друга:

f="/a/b/c.txt"
mkdir -p -- "${f%/*}" && touch -- "$f"
5
15.11.2013, 02:04
2 ответа

Это поведение легко объяснено через размер буфера вывода и настройки окна TCP.

Во-первых, при получении данных, у Вас или есть биты, или Вы не делаете. Ваше локальное scp знает, сколько это ожидает и сколько это получило до сих пор, таким образом, это может дать Вам точную оценку прогресса и оцененное время, оставаясь.

При отправке данных у Вас нет информации о том, сколько из тех данных на самом деле достигло получателя все же. Ваша локальная машина будет иметь буфер вывода, который содержит данные после того, как это было "отправлено" приложением (scp) и прежде чем это будет на самом деле передано в сети. Кроме того, TCP позволяет определенному количеству данных быть "в полете" между отправителем и получателем.

При отправке данных, scp только видит, сколько это передало к ОС для возможной передачи. Заполнение буферов вывода происходит действительно быстро, так вот почему scp измеряет высокую скорость передачи первоначально. В то время как передача прогрессирует, это значение сходится к реальной скорости передачи. После того, как Вы передали все данные к своей ОС, они все еще должны достигнуть другой стороны, и вот почему это, кажется, застревает в 100% в течение нескольких секунд в конце.

Современные сети OSes и TCP увеличили размер окна TCP (см., что окно TCP масштабирует опцию), составлять "длинные толстые сети" и с широкой полосой пропускания и с высокой задержкой. Именно поэтому можно видеть, что это поведение чаще, чем Вы имеет в прошлом.

11
27.01.2020, 20:34
  • 1
    Это имеет большой смысл, +1. Я беру его затем, что длинная пауза после достижения 100% является временем, которое требуется для передачи последних данных в буфере? Кроме того, почему я не вижу это поведение при копировании между высокопроизводительными серверами? –  terdon♦ 15.11.2013, 03:19
  • 2
    @terdon: поведение все еще там при копировании между любыми двумя серверами, это просто могло бы быть менее примечательно в зависимости от рабочих характеристик сети между ними. –  Greg Hewgill 15.11.2013, 03:51
  • 3
    @GregHewgill: +1, спасибо за то объяснение. Таким образом, Вы подразумеваете, что, когда scp застревает в 100%, это - потому что 100% данных были уже отправлены в ОС? И затем это вызывает другой вопрос: как scp знает, что еще не сделан? Я имею в виду, если scp полагает, что 100% передачи уехали, как прибывает, это знает, что файл полностью еще не передан? И если scp знает, что не полностью передается, почему не может он отображать "корректный" процент!? (как заметка на полях способом было бы "лучше", если бы это показало 99% вместо 100%: это немного менее сбивало бы с толку), –  Cedric Martin 15.11.2013, 04:48
  • 4
    @CedricMartin: scp просит, чтобы ОС сообщила, когда 100% данных были успешно получены к другому концу. Если бы scp завершился ранее, то могла быть проблема передачи, которая не будет обнаружена scp (потому что это уже закончилось). scp знает, что еще не сделан, но ОС не делает информацию о том, сколько было получено к другому концу, доступному приложениям (то есть, той информацией не является часть интерфейса сокета). –  Greg Hewgill 15.11.2013, 04:57
  • 5
    @GregHewgill ioctl с SIOCOUTQ должен получить объем буферизированных данных. По крайней мере, согласно документам в tcp(7), на самом деле не попробовали его. Но scp не может сделать этого, с тех пор ssh на самом деле обрабатывает сокет. –  derobert 30.03.2015, 17:35

Недавно я столкнулся с очень похожей проблемой, когда WireShark показывал ошибки TCP ZeroWindow всякий раз, когда я пытался передавать данные по ssh со скоростью, превышающей определенную. Наконец-то я проследил это до того, что на моем маршруте что-то напортачило с обработкой качества обслуживания IP. Добавление этой конфигурации в мою конфигурацию sshd _и конфигурацию ssh _исправило это:

IPQoS=af21 cs1

Эти настройки будут использоваться по умолчанию в более новой версии SSH, чем у меня сейчас:https://www.openssh.com/txt/release-7.8

0
27.01.2020, 20:34

Теги

Похожие вопросы