Эффект бутылочного горлышка в копировании.

Это происходит из-за буфера дисков/оперативной памяти?

да. прост осначала копируется в ОЗУ. А потом начинает потихоньку выгружаться на диск.

На буфер диска, а уже потом на диск. Правильно?

Если в cp и чём-то там ещё можно задать bs=65536, то как с этим в rsync?

Есть решение

Когда починят «ускоренное» копирование файлов в Linux? (комментарий)

а тебе что, сильно мешает неравномерность показываемой скорости?

Если в cp и чём-то там ещё можно задать bs=65536, то как с этим в rsync?

это тебе и в cp не особо поможет.

а тебе что, сильно мешает неравномерность показываемой скорости?

Мешает то, что скорость копирования в первые минуты 60 и больше мегабайт, а потом падает до 2-3МБ

и все? Тебе мешает только этот показометр?

И вообще, откуда и куда копируешь? На флэшку?

Смущает скорость копирования. Раньше копировал по usb2.0 переносного HDD на встроенный HDD и обратно. С флешками всё так же, думаю с HDD на HDD тоже будет скорость падать.

Смущает скорость копирования.

да все норм. Считай среднюю скорость, а не мгновенную.

Раньше копировал по usb2.0 переносного HDD на встроенный HDD и обратно. С флешками всё так же, думаю с HDD на HDD тоже будет скорость падать.

С HDD нв HDD должно быть около 80MB/s средняя (хотя может я с 3.0 путаю, в любом случае не меньше 30). По USB2.0 в принципе примерно так же должно быть. 2-3 MB/s - это с дешевыми флэшками только.

Копировать фс целиком через dd. Линейное io быстрее, чем куча мелких файлов.

Максимальная скорость USB 2.0 - 33Mb/s.

Это происходит из-за буфера дисков/оперативной памяти?

Да.

скорость копирования в начале нормальная, но через некоторое время падает на порядок.

А если особо «повезло» — при этом в дикий трешинг утаскивается вся система. Welcome to 12309.

Значит у меня USB3 на ноуте стоит.

autofsync

+1

Вот это просто образец прагматического решения проблемы, на самом деле. Просто, незатейливо и при этом семантически корректно.

просто ленин в своем репертуаре, по USB2 скорость 480Мбит/с (60МБ/с)

по USB2 скорость 480Мбит/с (60МБ/с)

Это теоретический предел. Можешь считать, что это как бы скорость передачи единичного бита. Но взаимодейтвие нужно как-то организовать, сложить данные в пакеты и переслать. Причём пакеты могут отправляться в определённые слоты времени, что ещё снижает скорость. Наверняка mass storage устройствам захочется передавать данные кусками с кратным степеням двойки размерами. Ну то есть, 4096 байт полезных данных из 5120 возможных. Вот ещё потеря скорости.

На практике выходит где-то 25-35 мегабайт в секунду. Где-то в интернетах писали, что на специфических задачах выжимали до 43 метров в секунду. Наверняка там фреймы заполнялись полностью.

просто ленин в своем репертуаре

Не может же он всегда ошибаться. Иногда и что-то близкое к реальности получается.

На практике выходит где-то 25-35 мегабайт в секунду

Побольше, где-то 40 обычно стабильно.
Хотя может, зависит ещё от контроллера (как самого USB, так и диска, SATA), загруженности

где-то 40 обычно стабильно.

Ты реально видел 40 мегабайт в секунду через USB 2.0?

https://youtu.be/_yZmbLrpWgs?t=1m16s

Лично пока подтвердить пока не могу - 2.5" винт, который работал с USB2.0 коробкой, стоит в ноутбуке, но насколько я помню, примерно такая скорость и была.
Да, не с USB на USB, а при копировании с/на внутренний винт, или при заполнении /dev/zero

Это ещё может зависеть от температуры диска и от фрагментации фс, когда головка скачет при копировании по разным местам.

Я таких скоростей на USB 2.0 не видел никогда. Но я помню, что знакомые, которым по работе нужно было во много компов подключать USB-HDD, говорили, что USB 2.0 диски при подключении к компам с USB 3.0/3.1 работают по ощущениям быстрее, чем при подключении к компам с USB 2.0. Но и то, максимум скорости был где-то на уровне 35 МБ/сек.

Сейчас попробовал у себя. USB-HDD с 2.0. Подключаю к ноуту с 3.0, получаю скорость чтения около 33 МБ/c. Подключаю к нетбуку с 2.0, получаю где-то 30 МБ/сек. Ради интереса подключил к нетбуку 3.0 коробку с SSD внутри, получил 35 МБ/c. То есть, его контроллер могёт, но в комбинации с 2.0 клиентом выше 30 МБ/с не поднимается. Было бы интересно тот жёсткий диск в 3.0 коробке проверить, но уж сильно сложно он разбирается.

Нашёл http://usb.userbenchmark.com/SpeedTest/7054/Samsung-S2-Portable, там оказалось довольно много результатов с 40-42.

но уж сильно сложно он разбирается

Делюсь секретом У меня всё уже в наличии. Могу сам проверить и отписаться.

Прикольная штука, спасибо.

Для nvme ещё не придумали внешних корпусов, кстати?

Придумали

бугага.

This is a software issue, Linux does not seem to currently support TRIM through USB. The problem is that USB storage devices employ the SCSI command set, whereas the SSD drive implements the ATA command set. The USB enclosure has to provide a translator between these command sets. The operation called TRIM in ATA is called UNMAP in SCSI and DISCARD in the Linux kernel. When Linux receives the command to trim a device, it looks up the correct command to be sent to the device. As USB storage devices look like SCSI disks, Linux tries to use UNMAP or a couple of other possible SCSI commands. In principle, the translator in the USB enclosure could often translate UNMAP requests to the corresponding ATA TRIM, although there are probably tricky cases. In practice, the enclosures don't do this, and they indicate instead that the device does not support UNMAP. However, many enclosures implement a SCSI command to issue ATA commands directly to the device. It is called ATA passthrough. There is a standard command to do this, but some enclosures have a proprietary command instead. In fact, hdparm -I uses ATA passthrough to get information from the device. The same passthrough could be used to issue TRIMs directly to the device, but the Linux driver does not currently do that. It would have to detect that a SCSI disk is actually a SCSI-to-ATA translator that supports ATA passthrough and use the passthrough for DISCARDs instead of the native SCSI commands.