LINUX.ORG.RU

и снова (но давайте более теоретически!?) про тормоза с USB-флешкой вопрос

 , freezing, ,


4

3

добрый день!

друзья!

этот вопрос задавался миллионы раз — но всегда появляется кто-то кто начинает давать *практические* советы как это исправить. пожалуйста, друзья, давайте на этот раз не будем тут писать практические советы (ими заполнен четь более чем весь интернет!).

вопрос: почему во время копирования больших файлов на медленный USB-накопитель (даже из не основного диска) — вся система начинает переодически подзависать включая курсор мыши?

интересует сугубо *технические* (теоретические) детали этого механизма, а не рецепты исправления этого. да(!) я хочу чтобы оно и дальше тормозило (не хочу это исправлять!), но при этом лучше понимать природу этих явлений.

понятное дело что вероятность появления тормозов зависят от железок. давайте разберём ситуации у людей, которым повезло заиметь соответствующие такие железки (такая мат-плата, и такая USB-флешка).

сможете помочь? заранее спасибо!

★★★★★

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

Потому что

Since the dawn of time, our background buffered writeback has sucked. When we do background buffered writeback, it should have little impact on foreground activity. That's the definition of background activity... But for as long as I can remember, heavy buffered writers have not behaved like that
https://lwn.net/Articles/698815/

anonymous
()

Ну и плюс это умножается на убогость fuse, если там нтфс, тормозность дешёвых флэшек на запись, оверхед usb относительно sata/nvme.

anonymous
()

Миллионы раз отвечали это набор ошибок, в том числе и экзотических, на одном компе такая фигня исчезла после смены шланга жесткого диска. Разработчик не сядет за каждый глюкавый комп, это не всегда воспроизводится, это ,повторюсь, множество ошибок, нет тут рецепта и теоретического обоснования.

ilovewindows ★★★★★
()

Это не излечимо, можешь перед началом копирования запустить скрипт: который следит за LA, в случае если оно стало больше например 8 или 10 начинает сбрасывать дисковый кэш.

У меня его нет, делал это вручную (сейчас редко копирую на флешки большие файлы)

LinuxDebian ★★★★
()

интересует сугубо *технические* (теоретические) детали этого механизма

Мои наблюдения, при копировании файла в 3ГБ:
1. Съедание всей оперативы дисковым кешем (8Гб)
2. Дисковый кэш не вытесняется другим софтом (либо, планировщик не ожидая такой фигни выгружает его слишком маленькими порциями, и он сразу же забивается тем самым еще больше нагружая ОС)
3. Даже если осталось пару сотень мегабайт, после сброса кэша ровно со скоростью чтения из отдающего устройства вся оперативка будет забита снова...

LinuxDebian ★★★★
()

сталкивался с этим только на интоловских машинах.
так что это либо ошибка в драйвере интеловских процессоров, либо в самих интеловских процессорах, либо в планировщике.
ну плюс ещё в линуксе что-то не так с работой usb — работает медленнее, чем на винде

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

Это не излечимо

ничего страного :-) . я и не собирался исправлять..

скрипт: который следит за LA

что за LA? имеется ввиду «load average»?

в случае если оно стало больше например 8 или 10 начинает сбрасывать дисковый кэш.

если даже это сработало бы — это не решит главый вопрос — пролить связт на вопрос какая связь между дибильной USB-флешкой и подзависанием всех остальных (не связанных с ней) программ :-)

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

что за LA? имеется ввиду «load average»?

Именно

пролить связт на вопрос какая связь между дибильной USB-флешкой и подзависанием всех остальных

Выше описал, связь прямая, - борьба за оперативную память, свободно 0, и планировщик ее чистит, а копирование забивает на скорости 100Мб/сек.

LinuxDebian ★★★★
()
Последнее исправление: LinuxDebian (всего исправлений: 2)
Ответ на: комментарий от teod0r

драйвере интеловских процессоров

anonymous
()
Ответ на: +1 от LinuxDebian

У меня на двух амуде вёдрах c разными чипсетами так, ваши оправдания?

anonymous
()
Ответ на: комментарий от user_id_68054

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

anonymous
()
Ответ на: комментарий от LinuxDebian

Дисковый кэш не вытесняется другим софтом

почему вдруг он перестаёт вытесляться другим софтом?

это же не нормально

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

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

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

Какие еще оправдания, - либо ты врешь, либо оно так и есть. Ты дал инфу исходя из своего опыта, я из своего.

Кстати, у меня тормозило копирование на слабенькой АМДшке в 3.3ГГц но строго на ntfs. Не уверен что это одна и та же проблема. Было пару раз исследовать не стал. (так как сменил ее новую: AMD265 -> FX-8370, после этого еще и глюки с отпадающим 3.0 ушли)

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

Кстати, что за проц, чипсет?

Intel(R) Core(TM) m3-7Y30 CPU @ 1.00GHz

про чипсет ничего узнать нельзя кроме как модель платы ноутбука:

	Manufacturer: Dell Inc.
	Product Name: 0WG9Y2
	Version: A00
user_id_68054 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Потому что это кэш записи. Его нельзя просто освободить, нужно записывать куда-то

а ну ясно

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

Я вообще не уверен что кэш на всю оперативу это нормально... Можно вычислить максимальные пропускные способности блочных устройств и дать в двойне там... (может это и бред, это я на вскидку)

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

В кэше надо держать то к чему обращаются несколько раз, на фика держать в кэше кинцо которое скопировали с места на место. Кто-то решил что если есть оператива то она не должна простаивать, теперь она забита мусором.

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

В кэше надо держать то к чему обращаются несколько раз, на фика держать в кэше кинцо которое скопировали с места на место. Кто-то решил что если есть оператива то она не должна простаивать, теперь она забита мусором.

ребят, ребят! ну вы что?

я думаю в оперативке, в области кеша — есть порции от двух файлов:

1. порция от файла кинца *источника* (SSD).

2. порция от файла кинца *назначения* (для USB-флешка). память которая со временем делат своё write-back-дело на физическую USB-флешку

наверняка память забита в основном {1} — и думаю это очень даже безобидно. так как это может быть освобождено в любой момент — более актуальными данными

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

версия про кэш на запись {2} — наверно отпадает?

2. порция от файла кинца *назначения* (для USB-флешка). память которая со временем делат своё write-back-дело на физическую USB-флешку

ядро же вот что говорит на USB-флешку:

[regular-user@plm-notebook ~]$ journalctl -k | grep -Fi [sdb]
Nov 12 12:40:24 plm-notebook kernel: sd 1:0:0:0: [sdb] 60549120 512-byte logical blocks: (31.0 GB/28.9 GiB)
Nov 12 12:40:24 plm-notebook kernel: sd 1:0:0:0: [sdb] Write Protect is off
Nov 12 12:40:24 plm-notebook kernel: sd 1:0:0:0: [sdb] Mode Sense: 45 00 00 00
Nov 12 12:40:24 plm-notebook kernel: sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Nov 12 12:40:24 plm-notebook kernel: sd 1:0:0:0: [sdb] Attached SCSI removable disk

так что версия про кэш на запись — наверно отпадает?

нет ведь получается ни какого write-back-режима для записиь на флешку?

user_id_68054 ★★★★★
() автор топика
Последнее исправление: user_id_68054 (всего исправлений: 2)

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

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

в моём случае exfat

Я в первый раз увидел 12309 на ядре 4.10, хотя флешками пользуюсь всё реже. Да exfat+fuse, железо давно не менял.

И флешка быстрая USB 3.0, и диски все то же быстрые SSD. И ОЗУ 16 ГБ с кучей свободной. А все равно весь ГУЙ раком встал.

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 2)
Ответ на: комментарий от ilovewindows

Миллионы раз отвечали это набор ошибок, в том числе и экзотических, на одном компе такая фигня исчезла после смены шланга жесткого диска. Разработчик не сядет за каждый глюкавый комп, это не всегда воспроизводится, это ,повторюсь, множество ошибок, нет тут рецепта и теоретического обоснования.

Со следующего утра ученик Фроу Кэтч запустил свой новый код на тестовом примерчике и тот, естественно, упал. Фроу Кэтч бросил мышкой об стенку и пошёл искать учителя.

- Мастер!, - Фроу Кэтч не поздоровался, не совершил положенных поклонов, не постучался, даже не посмотрел на монитор учителя.

- Мастер! Что же получается - чем лучше я постигну дао программирования, тем более сложные ошибки буду совершать? тем тяжелее их исправлять потом? и найти?

Мастер легко вышел из глубокой медитации и бросил косой взгляд на неработающую клавиатуру на соседнем столе. Фроу Кэтч инстинктивно попятился. Учитель Гоу Ту улыбнулся и устроился в кресле поудобнее.

- Однажды, очень давно, - начал он тоном человека, устроившегося в кресле достаточно удобно, чтобы рассказать всю историю апдейтов базы данных от сотворения мира со всеми спецификациями, - один совершенномудрый программист написал очень хороший и очень хорошо оптимизированный код. Он работал много-много лет, а потом программу с этим кодом продали одной большой-пребольшой фирме.

- ???!!!

- Да, именно этой фирме. У неё, как ты знаешь, много разных программ, и когда они попытались собрать купленный код на своём новом компиляторе, компилятор упал. И никто не знал, почему падает компилятор. Мастера со всего мира искали ошибку в компиляторе.

- И нашли?

- Конечно нашли, но код всё равно продолжал падать. Люди говорят, что там встретились великие ошибки двух великих мастеров древности. Такие ошибки не оставляют следов и отладить их невозможно.

- И чем дело кончилось??

- Легенда гласит, что специально для кода совершенномудрого программиста в компиляторе написали маленький обходной чёрный ход, - и учитель Гоу Ту снова погрузился в созерцание.

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

(Если кто-то вдруг не читал, это отсюда.)

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

А чего думать, никогда не видел что в начале копирования скорость большая, а после окончания копирования еще долго моргает индикатор. Какой вот смысл от этого? Можешь зайти в директорию с большим количеством файлов, первый раз медленно, второй раз мгновенно, если зайдешь через пять минут, то тоже мгновенно, а ты второй раз можешь и не зайти и это будет висет в памяти «пока не понадобится». Имхо, и со страничным свопом в памяти такая же хрень.

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

а нельзя например придумать чтобы это поведение было бы слегка огранниченным?

например чтобы кэши разных блочных устрйоств — не вымывали бы друг друга? или по крайней мере не делали бы это вот-прям-сразу.

точнее говоря не кеши блочных устройств, а кеши файловой системы, с учётом того к какой файловой системе относится точка монтированися

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

Неправильно, когда проявилась ошибка, мышка не висела на гвоздике «в стене», надо вернуть мышку на базу, вдруг это влияет.

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

сталкивался с этим только на интоловских машинах.

А я на AMD: Athlon 64 3000+ & Phenom II X4.

Причём на первом у меня система стоит на медленной флэшке. Операция по записи на неё подвешивает систему. Так надеялся, что с релизом 4.10:

улучшение управления обратной записью (writeback management, статья).

станет лучше, но нет.

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

Я в первый раз увидел 12309 на ядре 4.10

А там это как раз «починили» (см. выше).

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

на фика держать в кэше кинцо которое скопировали с места на место. Кто-то решил что если есть оператива то она не должна простаивать, теперь она забита мусором.

Для этого уже очень давно есть стандартное лекарство posix_fadvise с параметром POSIX_FADV_DONTNEED (удачное имя POSIX_FADV_NOREUSE испоганили, и более не используется). Удобно упакованное в маленькой утилитке nocache:

$ nocache cp -r ...

gag ★★★★★
()

Дурацкий вопрос. А хромоподобный браузер не открыт случайно в процессе копирования? Вот не знаю почему, но у меня на ноуте если закрыть хром, фризы пропадают

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

Ну там довольно простое 2d, а у браузеров многосклойный композит кучи текстур. Круче только в играх.

anonymous
()
Ответ на: комментарий от ilovewindows

В кэше надо держать то к чему обращаются несколько раз

А узнавать, что к этому будут обращаться несколько раз, надо через libastral.

Кто-то решил что если есть оператива то она не должна простаивать, теперь она забита мусором.

Оператива не должна простаивать. Для того, чтобы определять, что является мусором, а что нет, существуют специально обученные алгоритмы. И нет, 12309 происходит не из-за этих алгоритмов.

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