The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Драйвер NTFS от Paragon Software может быть принят в состав ядра Linux 5.15, opennews (??), 31-Июл-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


19. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +1 +/
Сообщение от Аноним (16), 31-Июл-21, 12:08 
С текущим драйвером NTFS понятно, что не так - он не умеет записывать и много чего ещё. Но что не так с драйвером FAT?
Ответить | Правка | Наверх | Cообщить модератору

50. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +4 +/
Сообщение от AlesanderYaemail (ok), 31-Июл-21, 13:10 
Вам наверное просто повезло, когда при копировании на флешку с FAT32 система не становилась колом.
А если колом и не становилась, то подвисала ощутимо. И было это не на одном компьютере.
Ответить | Правка | Наверх | Cообщить модератору

53. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  –4 +/
Сообщение от Онаним (?), 31-Июл-21, 13:12 
Э-э-э, а может не стоило железо с авиты брать? :D
Ответить | Правка | Наверх | Cообщить модератору

61. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +1 +/
Сообщение от AlesanderYaemail (ok), 31-Июл-21, 13:27 
Никогда, ничего, не брал на авито.
Пара компьютеров дома и кучка на работе, при копировании на флешки подтормаживает на всех.
Компы не супер пупер, но винда на них не подвисает при копировании.
Ответить | Правка | Наверх | Cообщить модератору

120. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +/
Сообщение от InuYasha (??), 31-Июл-21, 17:03 
Всегда, всё железо беру на авито.
Кучва компьютеров дома, при копировании на флешки подтормаживает на тех, где линуксовник. И не приведите боги вынуть флэшку сразу после "100%" - всё на хрен с корнем разломается, что чекдиском не всегда соберёшь.
Компы супер-пупер, но винда на них не подвисает при копировании.
- мой случай.
Ответить | Правка | Наверх | Cообщить модератору

193. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +/
Сообщение от Аноним (13), 31-Июл-21, 22:55 
О да несколько раз ловил что Линукс превращает содержимое флешки в кашу.
Ответить | Правка | Наверх | Cообщить модератору

286. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +/
Сообщение от Аноним (-), 02-Авг-21, 03:49 
> О да несколько раз ловил что Линукс превращает содержимое флешки в кашу.

А винды могут и весь системный диск с NTFS так. Зело больнее получается.

Ответить | Правка | Наверх | Cообщить модератору

100. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +2 +/
Сообщение от макпыф (ok), 31-Июл-21, 15:20 
Это называется 12309
Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

205. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +/
Сообщение от AlesanderYaemail (ok), 31-Июл-21, 23:46 
Это не 12309. Это кривая реализация планировщиков ввода- вывода. Причем любого, перепробовал все, нет ни одного нормального.
И что самое интересное, если записывать любую загрузочную флешку, то ничего не тупит.
Данные пишутся и там и там, но там тормозит при записи, а здесь нет.


Ответить | Правка | Наверх | Cообщить модератору

226. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +1 +/
Сообщение от Аноним (-), 01-Авг-21, 07:03 
> Это не 12309. Это кривая реализация планировщиков ввода- вывода. Причем любого, перепробовал
> все, нет ни одного нормального.

Жжошь! Эксперт системный, my a$$! Если смена планировщика не помогает - возможно, было дело не в нем?! Как минимум в старых ядрах был весьма специфичный прикол с page cache vs mem alloc.

Идея примерно такая: юзер пишет 100500 гигз на тормозной носитель типа флехи с скоростью записи мег в секунду. Ядро выделяет огромный дисковый буфер почти на всю оперативу для ускорения операции. Софт радостно отваливает т.к. буферизованая запись типа-закончилась (для операции записи у софта). Это неспешно спихивается на тормозную флешку, которая быстро не умеет. А тут приходит прога и требует дать ей гигаз рамы. Он как бы в теории есть, только занят вон тем добром. Ядро начинает чистить page cache пытыясь обеспечить проге аллокацию. Но поскольку флеха медленная, это занимает чертову тучу времени. Прога при этом висит на попытке аллокации памяти. А какие у кернела варианты? Либо дать память, либо обломать аллокацию, на что большинство прог довольно плохо реагирует.

В новых ядрах это пролечили - запретили тормозным носителям слишком большие буфера отращивать, оно так и разучилось прикалываться. Но наверняка возможно придумать более 9000 других способов сделать что-то странное. Поэтому 12309 - починен. А тупари думающие что у них вон тот баг могут еще 20 лет фикса ждать. Потому что про их баг (который другой) тупо никто не в курсе. А опеннет - не багтрекер и не мыллист кернела.

> И что самое интересное, если записывать любую загрузочную флешку, то ничего не тупит.

Используя dd чтоли? Там буферизация заметно иначе будет происходить нежели на уровне ФС. Однако некомфортный буфер vs тормозную флеху и так можно огрести. Но это тормозит только то IO.

> Данные пишутся и там и там, но там тормозит при записи, а здесь нет.

Логично - кэширование ФС при этом не у дел.

Ответить | Правка | Наверх | Cообщить модератору

256. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +/
Сообщение от СеменСеменыч777 (?), 01-Авг-21, 12:34 
> В новых ядрах это пролечили - запретили тормозным носителям слишком большие буфера отращивать

где ?
на ядрах 5.10.х я никаких изменений в этом вопросе не заметил.
до сих пор вручную ставлю vm.dirty_bytes=32768 перед большим копированием на флэшку.
иногда забываю вернуть обратно.

Ответить | Правка | Наверх | Cообщить модератору

287. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +/
Сообщение от Аноним (-), 02-Авг-21, 04:14 
> где ?

Ух, хороший вопрос, 12309 в багзиле спрятали, редиски. Видимо ламы не способные понять что багов бывает более 1 девов задолбали. Но это было сколько-то лет назад и в 5.10 это уже явно есть. Так что точные комиты сказать сложновато. Хоть и можно раскопать если сильно надо.

> на ядрах 5.10.х я никаких изменений в этом вопросе не заметил.

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

> до сих пор вручную ставлю vm.dirty_bytes=32768 перед большим копированием на флэшку.
> иногда забываю вернуть обратно.

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

Раньше это было примерно так: флеха на 8 гиг, запись ~пару мег в секунду, 4 гига спокойно улетает в буфер RAM, для софта это типа-готово. Реально оно потом еще эвон сколько в RAM висит. Вероятность что кто-то на эти гиги запретендует ессно не нулевая, а выжать столько на такую флеху занимает уйму времени и это время прога захотевшая ту оперативу будет тряпочкой, что не айс. А какие еще варианты? Сказать ей что памяти нет? Она скорее всего упадет тогда.

Сейчас ~полгига буферится (на компе с 16 гигз), потом ядро видит что флеха тормоз и перестает отращивать кэш, если запись не влезла в столько, дальше софт телепается с фактической скоростью записи флехи если надо больше. Так что в целом куда более вменяемая эвристика.

Я допускаю что какие-то случаи это не покрывает или кому-то надо что-то иное. Но это наверное уже другой баг.

Еще есть вариант когда система low on RAM. Тогда если системный диск тормоз может начаться thrashing по совсем другой причине: даже если у вас нет свопа, система может выкраивать оперативу отбрасывая страницы исполняемых файлов, если известно что это подперто диском и можно будет перечитать. При душняке памяти, особенно на механическом диске можно получить весьма неспортивный хруст диском. Это дурное наследие свопфайлов, и таки вот прям ща - есть специфичный выводок патчей, гугол их в хромооси юзает, и их в майнлайн пытаются загнать как раз. Но это иной случай, выглядит по другому. А из общего - эвристика mm дала лажу в энной ситуации.

Ответить | Правка | Наверх | Cообщить модератору

342. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +/
Сообщение от СеменСеменыч777 (?), 05-Авг-21, 20:01 
> А какие еще варианты? Сказать ей что памяти нет?

пусть висит на ожидении завершения I/O. в ядре есть или должен быть такой режим.

> Сейчас ~полгига буферится

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

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

Ответить | Правка | Наверх | Cообщить модератору

384. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +/
Сообщение от Аноним (-), 09-Авг-21, 15:08 
> пусть висит на ожидении завершения I/O. в ядре есть или должен быть такой режим.

Тот кто записывает? Так там есть такой режим, O_DIRECT. А глобально убить кэш ведет к перфомансу "на дворе MSDOS без smartdrv" и к этому пользователи уже не готовы морально как правило.

> это слишком много. 64КБайт вполне достаточно.

Не факт. Размер eraseblock порядка 4..32 мега, erase group и того больше, и в идеале лучше отправлять непрерывными кусками такого порядка по соображениям эффективности. Иначе скорость может просесть дополнительно с всяким write amplification.

> даже если сделают флэшки с большим размером кластера и сектора, больше этой цифры точно не будет.

У флешек намного более крупные "сектора" (erase block) унутрях, порядка 2^N мегабайтов. У продвинутых контроллеров флешек несколько и это еще помножить на число чипов флеша.

> вообще файловые страницы dirty есть смысл отращивать в памяти только при условии,
> что в те же места будут еще и еще записи (чего
> при простом копировании очевидно не будет).

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

Ответить | Правка | Наверх | Cообщить модератору

329. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +/
Сообщение от пох. (?), 05-Авг-21, 10:51 
> Это не 12309. Это кривая реализация планировщиков ввода- вывода.

12309 и есть кривая реализация планировщиков ввода-вывода (помножившаяся еще на пару совместных улучшизмов).


> Причем любого, перепробовал

до тебя уже все перепробовали, ищи 12309 в вебархиве - божок-с-пальцем запретил тебе читать оригинал, но копия еще не удалена, почитай внимательно. deadline _немного_ облегчал жизнь. (но и это тоже уже сломали)

Нет, это не драйвер vfat, с ext4 будет еще хуже, если не отключать журнал при создании.

Ответить | Правка | К родителю #205 | Наверх | Cообщить модератору

385. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +/
Сообщение от Аноним (-), 09-Авг-21, 15:17 
> 12309 и есть кривая реализация планировщиков ввода-вывода

У, пох, ты что-то системные скиллы совсем профакал. Это проблема page cache.

А планировщиков там море, но они вообще не помогут если прога ждет пока ей гиг памяти расчистят, выжав на того слоупока из кэша. Хоть как этот гиг планируй, а прога аллокацию памяти не получит пока не будет откуда это дать, это скоростью записи vs объем аллокации который надо почистить ограничено, планировщик то чем поможет? Фикс 12309 меняет отращивание кеша, лимитируя кэш для медленных носителей.

> (помножившаяся еще на пару совместных улучшизмов).

У тебя какие-то зело тухлые сведения по этим подсистемам, это какого года и для какого ядра?

> _немного_ облегчал жизнь. (но и это тоже уже сломали)

Они конкретно 12309 и воспроизвели и починили. Но как ты понимаешь, возможно более 9000 других странных взаимодействий. И тогда это новый баг. Я не знаю, тебя в твоем энтерпрайзе не учили что разные баги надо в отдельные кейсы класть? А когда дикие обезьяны гадятся под себя и не страдают минимальной культурой - ну их и приходится вот так, палкой по спине, они по другому не понимают походу.

> Нет, это не драйвер vfat, с ext4 будет еще хуже, если не
> отключать журнал при создании.

Это вообще от драйвера зависеть не должно в вон той ситуации.

Ответить | Правка | Наверх | Cообщить модератору

388. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +/
Сообщение от пох. (?), 09-Авг-21, 16:04 
page cache ни разу не в 2.6.17 появился.

Почему-то это не было проблемой.  А вот как раз планировщики там зацепили сильно.

> это какого года и для какого ядра?

12309 относится конкретно к 2.6.14-2.6.18
git bisect ВНЕЗАПНО никто сделать ниасилил или не захотел. Хотя размер изменений вполне позволял точно найти виновных. Вероятно, потому что все и так их знали. Но rhbm деньги уже перечислил.

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

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

Ответить | Правка | Наверх | Cообщить модератору

109. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  –1 +/
Сообщение от Аноним (109), 31-Июл-21, 16:06 
12309. Баг довольно давно известный и фиксится разными способами. Из геморройного — наложение патчей типа le9, из менее — установка значений vm.dirty_bytes и vm.dirty_background_bytes меньше дефолтных, например 4194304 (прописывать в /etc/sysctl.conf, применять перезагрузкой или sysctl -p).

Работает это из-за кривой реализации работы с дисковым кэшем, которая очень тормозит именно на медленных носителях (возникает race condition по-моему, — короче, очень медленно сбрасывается кэш записи на устройство). Мы уменьшаем размер дискового кэша, не давая ему набиться аж под 10% ОЗУ, и он чаще сбрасывается на диск.

Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

288. "Драйвер NTFS от Paragon Software может быть принят в состав ..."  +/
Сообщение от Аноним (-), 02-Авг-21, 04:17 
Да нет там никакого race, просто выжимка гигазов на флеху с скоростью записи пару мегов в секунду (таких легион) занимает уйму времени, чисто на уровне математики. И если память под огромным буфером, то единственный альтернативный вариант - послать прогу с аллокацией, но она тогда обидится.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру