Зависание в процессе копирования на USB
Видимо после недавних обновлений, система преподнесла интересный баг. В процессе копирования файла выше среднего размера (>300MB) через USB наблюдается задержка
2мин. Т.е. если смотреть по размеру, то файл уже передан, но процесс копирования лочится и висит ждет непонятно чего. Проблема возникает как при передаче файла через FM, так и в консоли.
Вот описание бага и временное решение: http://unix.stackexchange.com/questions/107703/why-is-my-pc-freezing-while-im. Проверено, помогает.
Но тут возникает дилемма — или ты копируешь с нормальной скоростью и потом ждешь рандомное время пока разлочится процесс, или ты копируешь с низкой скоростью 6-8mbps.
Если у кого то была похожая проблема, подскажите. пожалуйста, в какой версии ядра ее пофиксили
Ubuntu 14.04 LTS
На 3.12 и выше замечал что-то такое, сейчас на 3.16 уже нет.
Проапгрейдился на 3.16. Баг остался.
возникает дилемма — или ты копируешь с нормальной скоростью и потом ждешь рандомное время пока разлочится процесс, или ты копируешь с низкой скоростью 6-8mbps
нет никакой дилеммы — файл копируется с той скоростью, с какой флешка его может записать, просто файлы копируются через кеш OS и прогресс в FM показывает скорость записи в оперативку
это не баг, в офтопике тоже самое
там тупо кеш уменьшили, лучше уж эту древнюю флешку выкинуть, чем всю систему из-за неё портить)
Источник
Debian. Лаги при копировании файлов
Всем привет. Система Debian 8.1 с KDE 4. При копировании множества (великого множества) мелких файлов (а также их удаления), наблюдаются лаги в интерфейсе (к примеру тормозит анимация прогресса копирования и рамка выделения на рабочем столе), в редких случаях может начать подвисать курсор (замечено при копировании с Ntfs раздела на флешку). Проц Core i3-550, оперативки 8 гигов, планировщик CFQ, своп 2 гига. Читал www.linux.org.ru/wiki/en/User:shimon/12309 пробовал применять у себя. После установки vm.overcommit_ratio = 80 при загрузке падала плазма. Пробовал выставить vm.dirty_bytes = 2097152 и vm.dirty_background_bytes = 2097152, но так как проблема у меня возникает не всегда, проверить не удалось. Правильно ли я понял, что тут нужно указать количество своей оперативки в килобайтах? Что можно подкрутить в /etc/sysctl.conf чтобы убрать подлагивания? Стоит ли сменить планировщик на, скажем, Deadline (насколько я знаю, он в Ubuntu по умолчанию)?
забей, у людей либо этого бага нет (как у меня), либо есть/им так кажется и они занимаются не приносящим плоды плацебо без попытак установить причины
хотя можешь посмотреть perf top во время тормозов
Не даляй множество файлов через гуй, кеды при этом сильно проц жрут.
кеды при этом сильно проц жрут
Это хоть как-то можно исправить?
Ну планировщик проще поменять и посмотреть, чем ждать что здесь напишут.
Так как ntfs через user-space, то при больших копированиях просто сжирается процессор, а не диск, а так как KDE при этом крутит анимацию, то ему и не хватает. Должно немного помогать понижение приоритетов (renice, ionice) процессу ntfs-3g.
Я бы поднял объём свопа и добился, чтобы работало с ″vm.overcommit_memory = 2″, но, ИМХО, в вашем случае это особо не повлияет.
Хм. Поставил копироваться каталог с несколькими тысячами мелких файлов с ext4 на Ntfs — лагов нет. Нагрузка на проц 25%. Памяти ест немного. Ничё не понимаю. Утром копировал с внешнего винта на ext4 — были лаги в анимации. А создавал позавчера загрузочную флешку с оффтопиком — вообще подвисала система пару секунд.
Это, по всей видимости, проявление общей проблемы при копировании с быстрого устройства на медленное. KDE и прочая нагрузка на процессор здесь совершенно ни при чём. А «при том» то, что один процесс забивает нахрен всю квоту грязных страниц в дисковом кэше, и следующий же процесс, вознамерившийся что-то записать (или, того хуже, сделать fsync) вынужден ждать записи в медленное устройство.
Источник
Когда починят «ускоренное» копирование файлов в Linux?
Итак, дано: Ubuntu 16.04.4, Fedora 27.
И там и там есть один баг, которому уже много лет, я даже честно не знаю сколько.
Суть бага: прогресс показывает сначала очень высокую скорость копирования, доходит до отметки примерно в 60% и врубает тормоза. У меня бывало так, что на Ubuntu 2-3 гигабайта копировались на флешку за пару секунд, а потом удовольствие растягивалось еще на 20 минут, при этом объем передаваемых данных равен 8 гб, понятное дело, что это баг, но ему уже сколько лет! Когда починят то? Забавно, но cp при этом показывает равномерную скорость копирования и в серверной Ubuntu я спокойно копирую данные в 500 гигабайт между ЖД без проблем.
Но у меня Linux на десктопе и черт побери, он в 2018 еще не готов для массового пользования, когда такие детские баги вылезают.
Это баг разве? Я думал, так и задумано.
Да не знаю, но у меня уже прикипело видеть: 4.3 из 4.4 ГБ — осталось 14 секунд. И так 4 минуты уже.
Ну все правильно, у тебя часть файла оседает в кеше фс. Пока забивается кеш фс, копируемся быстро. Если файл меньше размера кеша — будем подвисать на размонтировании. Не нравится — отключи кеш фс, или сделай его очень маленьким.
Ну, мне тоже не особо нравится такое поведение. Я полагаю, он сначала кэширует данные в память, а потом начинает реальную запись. Можно попробовать понизить значение vm.dirty_ratio/vm.dirty_background_ratio, по идее, они должны как-то на это влиять.
Я знаю одно место, куда файлы можно копировать без задержки, /dev/null называется.
Проблема может быть в железе. Погляди smart. Я тут прикупил 10 ТБ винт и у него тоже такая проблема была — как выяснилось это он так плохие сектора передислоцировал. В общем проверки badblocks он уже не пережил. Придёт теперь сдавать диск по гарантии.
На 4х HDD дисках, двух флешках и одном SSD такая проблема.
Значит ровно столько влезает в оперативку, а потом грустно и долго идёт запись. Чудес не бывает или /dev/null.
В любом случае глянь smart.
Да не, со смартом 146% все ок. А оперативки, ну вот не знаю, есть ноутбук, на нем стоит Windows 10. Там два гигабайта оперативной памяти, все работает окей, кроме хрома, что понятно. С копированием в 18м году проблем также нет.
Стоит Ubuntu 16.04, Intel I5-4670, 16 гигабайт памяти, и епрст, система не может нормально скопировать файлы, тут вряд ли проблема в ОЗУ. Через cp -av все копируется гладенько, как и должно.
Я теперь тяжелые каталоги через cp и перемещаю. В десктопной убунте. Смешно.
1. Ты же правда в один поток копируешь? флешки фактически не умеют даже в два потока.
2. Почитай что такое «отложенная запись» цифры от cp при записи на flash направляй в /dev/null.
никаких багов нет, есть простое незнание «как оно работает».
При чем здесь CP? Оно идеально работает. Я говорю про то, что десктопная Ubuntu не может «равномерно» показывать прогресс копирования файла и постоянно врет.
много раз слышал и не понимал в чем подвох — потому что не наблюдал никаких замедлений, пока не установил козырнячий ssd — вот при копировании с него и начались дикие тормоза — даже на соседний винт hdd, а на флешки вообще капец. сам ssd работает шустро — старт системы, установка пакетов, запуск браузера все это происходит очень быстро — намного быстрее нежели система установленая на hdd.
Ты плохо понимаешь суть момента, сейчас так софт никто не пишет. Сейчас время не исправлять баги, а разрушать старую инфраструктуру.
Кстати да, я с ссд копировал.
Всё правильно. На винде такое же поведение. man кеш.
На Windows все четко.
windows nt в 1997 году на 3х дюймовые дискеты файлы копировала точно также. Это фича, но ты можешь уменьшить размер кеша на запись и копирование на флешку перестанет возмущать твоё чувство прекрасного 🙂
Я говорю про то, что десктопная Ubuntu не может «равномерно» показывать прогресс копирования файла и постоянно врет.
Это гном что ли? дикий хохот. гном сделан для того чтобы следовать хигу, быть похожим на мак и быть ваще, а не для того чтоб работать. на такие вещи, как врущий индикатор копирования, если конечно он хипстероугодно выглядящий, никто не обращает внимания.
cp на самом тоже врёт при отложенной записи. все врут.
Монтируй флешку с опцией sync
windows nt в 1997 году на 3х дюймовые дискеты файлы копировала точно также.
Вот тут ты врешь
Сам видел. 2х процессорный пентиум про 200МГц как сейчас помню. У меня самого тогда пень 166 ММХ был с 95й виндой.
Эти крутилки нужны для каждого блочного устройства. И желательно, в секундах, а не в байтах.
Плюсую. А конкретно для решения заявленной ТС-ом проблемы достаточно подкрутить vm.dirty_background (bytes или ratio) на что-то более-менее соизмеримое с пропускной способностью USB.
iostat -d 1 что показывает до начала тормозов и после?
Никогда не видел как в винде шкальник копирования доходил до 100% и там зависал на сутки?
Не рассказывай мне байки из склепа,не было такого никогда
У тебя неправильный шиндоуз; помню, на спермёрке охреневал от прогрессбара в эксплорере: сразу добегает почти до конца, а потом ползёт по чуть-чуть. И насколько я понял, это тупо свистелка такая для тупых хомячков — напоминает J2ME-трояны с прогрессбаром, в которых надо тыкать Fire для «ускорения» прогрессбара (на деле он вообще без этого не движется) — чтобы доверчивая жертва по инерции подтвердила пермишшон на отправку SMS. В десятке, насколько помню, в этом ничего не поменялось; зато добавили в диалогах копирования красивый и подробный график, тут лялипсу ещё долго ползти, эге. Установщик с восьмёрки в том же репертуаре: почти час пишет что-то в духе «подождите ещё немного», «осталось совсем чуть-чуть», «ну вот буквально через пару мгновений», «я ещё недолго, мамай клэнус!».
Это не баг а фича. А если ты пихаешь на флешку гигабайты мелких файлов, то большой скорости и не жди — лучше перед передачей пожать их архиватором без сжатия кусками по полгига.
Я как-то поднимал эту тему с GNU / Linux Debian. Мне вроде намекали, что я идиот и железо у меня кривое.
Когда починят «ускоренное» копирование файлов в Linux?
Попробуй поставить по крону с интервалом в 1 сек — /bin/sync.
Не рассказывай мне байки из склепа,не было такого никогда
Если ты такого в своем склепе не видел, то возможно это связанно с тем, что у упомянутого 200мгц-го п про были невероятные по тем временам 128М ОЗУ и винда легко могла закешировать на запись жалкие 1.44М дискеты.
В те времена ходили анекдоты типа «пап, покажи многозадачность виндовз 95. Сейчас сынок, дискетку доформатирую». А тут такое чудо — копируешь 1М файл на дискету мнгновенно, а он перез пару секунд после окончания записи включает светодиод и начинает жужжать. И не тормозит при этом.
Но у меня Linux на десктопе и черт побери, он в 2018 еще не готов для массового пользования, когда такие детские баги вылезают.
Поздравляю. Ты нашёл одну из самых меньших проблем линуксах на десктопах, на котороую всем плевать по большому счёту. В том числе под вендой.
Источник
