LINUX.ORG.RU

Долбаные флешки и линукс, долбаный

 , ,


2

2

Есть флешка, есть ссд, есть хдд.

Эксперимент номер 1: Когда пишем флешку примонтированную с «flush» и без O_SYNC - ядро набирает весь файл в dirty_cache, а потом при close приходит «flush»(благодаря моунт опции) и видим прогресс бар, который 0 -> 100% сделал незаметно для глаза и на 100% висит пол дня.

Эксперимент номер 2: Пишем ту же флешку тока с ::open(..., O_SYNC | ...) учитывая хардварный чанк который она может принять за одну отправку. Моя флешка может принять 1 мегабайт. Херачим чанками read -> write по метру и видим адекватный прогресс бар и адекватную скорость.

Эксперимент номер 3: Берём ssd без моунт опции flush и без O_SYNC - ядро нихера не диртикешит весь файл за один мах, и прогресс бар ведёт себя адекватно. С хдд та же фигня.

Отсюдова вопрос, ватзефак? По каким признакам ядро так не любит выдёргиваемые устройства? Как убедить ядро накапливать для моей флешки 1 мегабайт и отсылать на запись, а не принимать 100500 врайтов за 10ms, а потом проталкивать в панике грязные страницы в девайс? Причем, если выкрутить в минимум dirty_cache(при котором не перестают виснуть, схерато(??), десктопные приложения) то соответственно прогресс бар ведёт себя почти адекватно. Чуток разогнавшись, на те свои 50 мегабайт диртикеша, и дальше запись идёт как обычно до конца файла, ну и потом на close чуть висит пока допишет свои 50 мегабайт.

Че крутить, куда копать? Можно конечно в моих кедах накостылить в kio проверку и добавлять к определённым ::open опцию O_SYNC(что я сейчас и сделал), тогда адекватность присутствует, но хотелось бы в корне решить этот вопрос. Колупание сырцов ядра откладываю на самый последний вариант.

★★★

Это нерешённая проблема. И раз это в development, копать нужно в сторону отдельных dirty-лимитов на разные устройства. Лично мне кажется, что логичным будет ограничивать не объём грязного кеша, а время линейной записи. Например, одну секунду. Для флешки это будет мегабайт пять, а для жёсткого диска мегабайт сто. Пользователю будет удобнее время настраивать, чем объёмы.

Говорят, помогает включение multiqueue (добавь в параметры ядра: dm_mod.use_blk_mq=Y scsi_mod.use_blk_mq=Y) на относительно свежих ядрах. Там вроде как есть cache pressure, который агрессивнее сбрасывает dirty данные на носитель. Я на глаз разницы не заметил, но вроде чуть лучше стало.

Есть ещё вариант с реализацией периодических fsync'ов в самих файловых менеджерах, через которые копируются данные на флешки.

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

Writeback throttling запилили же с чем-то вроде этого, правда насколько помогает не проверял.

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

dirty_cache per device решил бы в какой-то мере вопрос. Но опять же таки, если не отталкиваться от того, что такая-же точно запись на hdd не приводит к столь агрессивному кешированию. Тобишь запись 700 мегабайт на hdd продвигается по ~140 мегабайт на секунду, что есть лимитом скорости моего hdd, без O_SYNC и без fsync'ов между врайтами. Т.е. линейный цикл из последовательности read -> write. Такая-же операция на флешку приводит к скорости записи овер 500 мегабайт в секунду, ибо цикл пролетает мгновенно. Вот сейчас пытаюсь разобраться, в чем разница для ядра между hdd и флешкой.

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

а, и мульти очередь у меня была включена до тех пор, пока я не начал наблюдать на всех ноутах залипы после суспенда, I/O ставал колом. Хотя и с ней видимой разницы не было особо.

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

флешка 3.0. Запись где 20 мб/с. Не думаю, что в этом дело

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

Но беда не только с флэшками - если что-то пишет на диск - остальное не может прочитать или записать ни килобайтика. Вот кто бы Линусу показал то, что он любит другим. Критичная проблема. Одна программа парализует систему - это само-DoS. При первом подозрении на DoS все бегут фиксить мигом, а тут натурально, какой-нибудь индексатор запускается непрошенный в линуксе - и всё помирает.

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от vova7890

такая-же точно запись на hdd не приводит к столь агрессивному кешированию

Ложь. Точно так же к чертям забивается и начинает тупить. Простейший пример - создание preallocated образа в виртуалбоксе размером в пару раз больше объема рамы хоста.

pekmop1024 ★★★★★
()

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

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

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

Да нет разницы, при записи на hdd из чего-то быстрого типа tmpfs точно так же улетает. Просто ты при записи на hdd ещё и читаешь с hdd, скорости практически одинаковые. А при записи на флешку ты читаешь с намного более быстрого устройства. Это либо hdd, у которого скорость в 20 раз больше, либо из кеша в памяти.

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

Ради чистоты ыксперимента копирование произвожу с tmpfs файл ~700 мегабайт.

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

Ну короче у меня есть несколько флешек, которые ведут себя по-разному. Одни нормально, другие - как ты описываешь. В чем между ними разница, я не знаю.
Вот только помню, что те которые работают нормально в KDE3 почему-то имели иконку жесткого диска, а тормозяшие - иконку флешки (Да, это настолько древние флешки, что еще помнят КДЕ3).

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

ну и тогда как объяснить

dd if=/dev/zero of=/dev/sda на флешку ^C пол дня отрабатывает ибо dirty_cache засрался и сбрасывается на носитель. А на hdd/ssd отрабатывает моментально, даже с учётом того, что хдд словпоке?

vova7890 ★★★
() автор топика

Так и есть. Решаю, выполняя в консоли sync. Даже от имени пользователя работает.

ZenitharChampion ★★★★★
()

Попробовать подцепить SSD в контейнер внешних дисков и подключить к USB. Интересно, также как флэшка будет себя вести?

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

Тоже думал проверить, но впадлу было выкорчёвывать свой усб3.0 переходник на сату. Выкорчевал, прицепл к нему жд. Скопировал файл - та же фигня шо и с флешкой. Оч интересно. Хотя в ноуте ещё торчит hdd в сата - все норм с копированием, правда на ntfs. Нада fat32 попробовать

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

лол, оказалось для ntfs сыграла свою роль fuse, в остальных безфузовских случаях - везде одинаково. Таак... Кажется после приобретения ssd я забыл про линуксопроблемы ))

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

ну и тогда как объяснить

Если бы я мог объяснить, уже послал бы патч в рассылку. Что за глупые вопросы.

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

fuse

Ну это ваще без комментариев.

anonymous
()

ещё у нас есть опция монтирования sync, которая очень страшно работает и скорость записи оказывается на уровне 1мб/с. Я так понимаю она вообще не учитывает размер блока который можно засунуть в одной посылке и шурует по-секторно. Осталось изобрести что-то среднее, что будет накапливать чанк для посылки и только тогда сбрасывать минуя диртикеш.

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

На линейных операциях совсем не слоу, особенно по сравнению с флэшками.

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

Ну тебе в первом посте написали решение, ставь dirty_bytes сколько нужно и будет так, правда общее для всей системы.

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

это не решение, а смерть для ssd. Лучше ld_preload хук на опен сделаю тогда для определённых моунт-поинтов -_-

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