Нужен тег 12309

Потому что

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/

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

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

Это тоже верно.

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

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

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

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

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

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

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

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

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

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

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

+1

Кстати да, на АМД я такого не видел. А вот на работе на i7 довольно часто проскакивает.

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

Именно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	Manufacturer: Dell Inc.
	Product Name: 0WG9Y2
	Version: A00

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

а ну ясно

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

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

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

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

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

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

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

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

версия про кэш на запись {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-режима для записиь на флешку?

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

Рандомно эта хрень происходит.

рандомно. да.

в моём случае exfat (тоже fuse — так что всё одна хрень)

Это же характеристики устройства. И кэш тоже устройства, видимо.

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

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

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

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

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

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

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

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

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

- ???!!!

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

- И нашли?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это про аппаратный кэш, программный есть всегда, если его не обходить намеренно.

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

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

$ nocache cp -r ...

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

А если что угодное с тяжёлым использованием памяти вместо хрома открыть?

Именно хром. GIMP + Darktable + Inkckape вообще никак не мешают

я один раз словил 12309 из-за vlc, который отожрал всю память

А если тогда что то использующее видеокарту и одновременно жручее на память?

12309 из-за vlc, который отожрал всю память

Ну это и не 12309

например? Darktable не подходит под описание?

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

Ну это и не 12309

ну я хз. а почему ты думаешь, что не 12309?

Потому что без всякой записи на флэшки при нехватке памяти всё колом встаёт.

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

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

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

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

Да. Firefox тоже с флешкой не совместим.

BFS, MuQSS

Вообще никак не помогают с этим, и не относяться сюда.