LINUX.ORG.RU
ФорумTalks

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

 , , , ,


0

1

Ситуация: есть файл или файлы, скорость копирования в начале нормальная, но через некоторое время падает на порядок. Почему так происходит? Это происходит из-за буфера дисков/оперативной памяти? И может быть ещё из-за создания каталогов/директорий? Как с этим бороться? В rsync, например? И вообще rsync это сейчас стандарт копирования файлов, или есть что-то ещё?

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

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

dikiy ★★☆☆☆
()
Ответ на: комментарий от just_a_brake

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

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

dikiy ★★☆☆☆
()
Ответ на: комментарий от dikiy

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

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

just_a_brake
() автор топика
Ответ на: комментарий от just_a_brake

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

dikiy ★★☆☆☆
()
Ответ на: комментарий от dikiy

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

just_a_brake
() автор топика
Ответ на: комментарий от just_a_brake

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

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

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

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

dikiy ★★☆☆☆
()
Последнее исправление: dikiy (всего исправлений: 1)

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

nvidia
()

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

Да.

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

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

intelfx ★★★★★
()
Ответ на: комментарий от greenman

autofsync

+1

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от TheAnonymous

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

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

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

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

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

i-rinat ★★★★★
()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от i-rinat

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

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

TheAnonymous ★★★★★
()
Ответ на: комментарий от i-rinat

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

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

TheAnonymous ★★★★★
()

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

xwicked ★★☆
()
Ответ на: комментарий от TheAnonymous

Я таких скоростей на 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 коробке проверить, но уж сильно сложно он разбирается.

i-rinat ★★★★★
()
Ответ на: комментарий от just_a_brake

бугага.

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.

TooPar
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.