LINUX.ORG.RU
ФорумTalks

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

 ,


10

5

Итак, дано: Ubuntu 16.04.4, Fedora 27.

И там и там есть один баг, которому уже много лет, я даже честно не знаю сколько.

Суть бага: прогресс показывает сначала очень высокую скорость копирования, доходит до отметки примерно в 60% и врубает тормоза. У меня бывало так, что на Ubuntu 2-3 гигабайта копировались на флешку за пару секунд, а потом удовольствие растягивалось еще на 20 минут, при этом объем передаваемых данных равен 8 гб, понятное дело, что это баг, но ему уже сколько лет! Когда починят то? Забавно, но cp при этом показывает равномерную скорость копирования и в серверной Ubuntu я спокойно копирую данные в 500 гигабайт между ЖД без проблем.

Но у меня Linux на десктопе и черт побери, он в 2018 еще не готов для массового пользования, когда такие детские баги вылезают.


Ответ на: комментарий от ValdikSS

Попробуете bisect? Я пока не добрался, сначала разбирался с этим, а сейчас ищу проблемный коммит здесь (это всё другие проблемы, просто к слову, что сложа руки не сижу, просто всё проверить физически не успеваю).

RussianNeuroMancer ★★★★★
()

На 50% делай watch sync в эм.терминала во время проблемного копирования как варик

Deleted
()

какой же это баг. это говнофлешка и брат её контроллер

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

Да что-то я поторопился, не настолько хорошие улучшения на 4.9, как хотелось бы. Самое серьезное зависание всегда вызывает VirtualBox. Он использует собственный модуль ядра, и, возможно, не совсем стандартно выделяет память. Может, проблема в нем, а не в ядре? Устрою еще тесты чуть позже, на другом компьютере, с меньшим количеством оперативки, и без VirtualBox.

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

Не исключено, конечно, тогда и мне все-таки нужно будет попытаться потестировать конкретно а моем use-case.

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

По предварительным данным фатальное изменение наступило между 4.11 и 4.12. Буду ещё тестировать, если многократно подтвердится, то начну bisect.

Но может быть у вас есть идеи, насчет того, какой коммит попытаться откатить? Bisect на доступном мне оборудовании, да с имеющимся количеством свободного времени, у меня займет недели.

RussianNeuroMancer ★★★★★
()

Не готов

На самом деле, ничто не мешает следить за тем, какие блоки были физически записаны на устройство, и сообразно отображать прогресс записи. Просто это сложно, и не знаю, есть ли у ядра для этого подходящие API. Поэтому все делают вид, что так и надо, а виноват во всём тупой юзер.

Pacmu3ka
()
15 апреля 2019 г.

Не жди, когда починят. Чини сам.

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

Да вроде и не нужно пересобирать. Зависимость там только от libc6, а она практически всегда обратно-совместима.

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