LINUX.ORG.RU

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

 ,


9

5

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

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

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

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


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

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

RussianNeuroMancer ★★★★★ ()

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

linux-org-ru ()

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

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

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

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

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

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

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

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

RussianNeuroMancer ★★★★★ ()

Не готов

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

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

А вы пробовали отключить различные обходы для spectre/meltdown/etc? Может, в этом дело?

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

Возник вопрос – при каких обновлениях системы нужно пересобирать autofsync? Или не нужно вообще?

greenman ★★★★★ ()

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

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

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

i-rinat ★★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)