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

"Применение асинхронной буферизированной записи на базе io_uring до 80 раз снизило задержки в XFS "	+/–
Сообщение от opennews (??), 26-Июн-22, 22:47
Опубликована серия патчей для включения в ядро Linux 5.20, добавляющая поддержку асинхронной буферизированной записи в файловую систему XFS при помощи механизма io_uring. Предварительные тесты производительности, проведённые при помощи инструментария fio (1 поток, размер блока 4кб, 600 секунд, последовательная запись), показывают увеличение числа операция ввода/вывода в секунду (IOPS) от 77k до 209k, скорости передачи данных от 314MB/s до 854MB/s и падения задержек от 9600ns до 120ns (80 раз)... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57412
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Применение асинхронной буферизированной записи на базе io_ur..."	+28 +/–
Сообщение от Аноним (1), 26-Июн-22, 22:47
Оказывается, если данные на диск не записывать, то "запись" будет быстрее. А что с надёжностью?
Ответить | Правка | Наверх | Cообщить модератору

	4. "Применение асинхронной буферизированной записи на базе io_ur..."	–20 +/–
	Сообщение от Catwoolfii (ok), 26-Июн-22, 22:57
	XFS - это не про надежность
	Ответить | Правка | Наверх | Cообщить модератору

	5. "Применение асинхронной буферизированной записи на базе io_ur..."	+5 +/–
	Сообщение от microsoft (?), 26-Июн-22, 22:59
	Твои варианты? А, да, их нет.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Применение асинхронной буферизированной записи на базе io_ur..."	–9 +/–
	Сообщение от Аноним (19), 27-Июн-22, 00:20
	ZFS
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Применение асинхронной буферизированной записи на базе io_ur..."	+15 +/–
	Сообщение от d (??), 27-Июн-22, 02:51
	Только не допускайте этого онанима до прода.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Применение асинхронной буферизированной записи на базе io_ur..."	+2 +/–
	Сообщение от Аноним (64), 27-Июн-22, 11:09
	Уже допустили. Начиная с 2020 года ZFS работает очень даже неплохо. Особенно после фикса тонны багов с read-range-locks. А снэпшоты - вещь которая продаётся как отдельная услуга. Но вот лично вам я разрешаю и дальше плеваться и фыркать на анонимов и ZFS.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Применение асинхронной буферизированной записи на базе io_ur..."	+2 +/–
	Сообщение от Аноним (65), 27-Июн-22, 11:12
	О а вот еще один фикситиль багов на проде.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Применение асинхронной буферизированной записи на базе io_ur..."	+4 +/–
	Сообщение от d (??), 27-Июн-22, 11:32
	> Особенно после фикса тонны багов с read-range-locks. Ну всё, теперь можно в прод.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	111. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (64), 27-Июн-22, 19:01
	5 лет в проде.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от zfsixpert (?), 27-Июн-22, 17:32
	только оперативы нужо 30% от размера хранилища
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	110. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (64), 27-Июн-22, 19:01
	Нет не нужно. Размер ARC-кеша настраивается. А вы, батенька, как я вижу - эксперт.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от keydon (ok), 28-Июн-22, 05:39
	С 2017 года, полёт нормальный. А критики могут и дальше ничего не использовать.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	165. "Применение асинхронной буферизированной записи на базе io_ur..."	–1 +/–
	Сообщение от bOOster (ok), 28-Июн-22, 18:39
	Сочувствую компаниям которых плюсующие этого поста админят..
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	168. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от tty0 (?), 28-Июн-22, 23:00
	Вообще-то прод - это не место, где резвятся обезьянки. Обычно там настроили, запустили и фиксы только самого необходимого. Фиксы ФС - это для талантливых!
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от pda (ok), 28-Июн-22, 11:46
	Ты бы ещё BtrFS посоветовал.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	194. "Применение асинхронной буферизированной записи на базе io_ur..."	–1 +/–
	Сообщение от Аноним (194), 01-Июл-22, 21:23
	бтрфс кстати очень годна для / Пакует опять же, нет танцев с монтированием/импортом как zfs, а глагне - работает (с холодными кешами) быстрее. Раз в 10 -- чем zfs и чуть быстрее - чем ехт4. Тестировал тупо чтение всех файлов с рутового раздела с холодными кешами. Снапшоты опять же делаются юниксвейно а не через отдельный анус, приштопанный сбоку, как в zfs. Главное -- не юзать бтрфс для образов диска вирт машин, вот там оно тормозииит... Ну и раид5/6 ни в коем случае в бтрфс не делать, бо сломано официально уже лет 10. И чинить никто не чешется.
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Michael Shigorin (ok), 03-Июл-22, 22:05
	Один из здешних завсегдатаев упоминал http://lore.kernel.org/linux-btrfs/20200520013255.GD10769�...
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от rationalseed (?), 03-Июл-22, 20:57
	BRTFS - рулёз!
	Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

	12. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Dzen Python (ok), 26-Июн-22, 23:46
	Ну как с надежностью - буфер пролюбили и ВСЁ!
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	17. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от Alladin (?), 27-Июн-22, 00:14
	Да, с этим вечно сталкивался.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Применение асинхронной буферизированной записи на базе io_ur..."	+2 +/–
	Сообщение от Аноним (70), 27-Июн-22, 12:12
	Я еще под досом ставил SmartDrv в режим кэширования записи. Девачка, чето хотевшая скопировать на дискету и по привычке выдернувшая дискетку сразу после завершения записи, ушла в итоге ни с чем.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	101. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 27-Июн-22, 18:19
	Сейчас видите ли журналирование научились делать немного лучше, а юзеров - строить "безопасным извлечением". Хотя подобную траблу конечно можно отхватить и сейчас. Собссно лампочки HDD/флопиков/флешек/... придумали не просто так.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от commiethebeastie (ok), 27-Июн-22, 20:19
	Так дискеты дергать с горящей лампочкой нельзя. Дефачке видимо это никто не объяснял.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	117. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (117), 27-Июн-22, 21:11
	Так со smartdrv лампочка, то и не горит! Она потом, через несколько секунд загорится. А дискеты уже то и нет.
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от pda (ok), 28-Июн-22, 11:49
	А на кой хер ты на дисководы кеширование записи разрешал? В этом же не было никакого смысла? Дискеты уже тогда использовались исключительно в режиме "записал, вынул и ушёл".
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	166. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (166), 28-Июн-22, 19:14
	Над девочкой постебаться же. Что за админ, если над юзером не поизмывался?
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Применение асинхронной буферизированной записи на базе io_ur..."	+4 +/–
	Сообщение от Аноним (170), 29-Июн-22, 01:59
	Крайне хреновый админ, очевидно. Юзеров надо любить, беречь и всячески упрощать их жизнь, а не чесать об них своё воспалённое эго. А чмудаков, начитавшихся bofh.txt и не распарсивших юмор обычно долго на должности не держат. А то и вовсе могут лицо отформатировать.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от pda (ok), 29-Июн-22, 12:32
	> Над девочкой постебаться же. Что за админ, если над юзером не поизмывался? Здравствуйте, "Наш BOFH"...
	Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

	182. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от Аноним (-), 29-Июн-22, 17:52
	> Над девочкой постебаться же. Что за админ, если над юзером не поизмывался? Сейчас флешки и получше стебаться умеют. Вынули без размонтирования? А вот вам слетевший транслтор, нелохи, если что-то с флешки надо - добро пожаловать в тематичную лабу.
	Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

	108. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от anonymous (??), 27-Июн-22, 18:37
	udp же
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Применение асинхронной буферизированной записи на базе io_ur..."	–4 +/–
Сообщение от achtosluchilos (ok), 26-Июн-22, 22:47
Ничего не понятно за счет чего получаются такие результаты. Автор новости пиши для орков, не для эльфов. Эльфы они в Шотландии.
Ответить | Правка | Наверх | Cообщить модератору

	8. "Применение асинхронной буферизированной записи на базе io_ur..."	+7 +/–
	Сообщение от Аноним (8), 26-Июн-22, 23:10
	в Шотландии леприконы, а в Англии рептилоиды, запомни.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Применение асинхронной буферизированной записи на базе io_ur..."	+2 +/–
	Сообщение от PnD (??), 27-Июн-22, 11:21
	Лепр*е*коны же! ИЧСХ, в Ирландии. https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c... В Шотландии — хаггисы (не подгузники) и пуки всякие. А, ну и Несси в одном из местных лохов.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от Аноним (-), 28-Июн-22, 10:53
	Для тех кто не понял. "Лох" в переводе с шотладского означает "озеро".
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от другие анонимы (?), 28-Июн-22, 14:42
	Да поняли мы, поняли - те, другие лохи - они в Несси, а не наоборот.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Применение асинхронной буферизированной записи на базе io_ur..."	+5 +/–
	Сообщение от Dzen Python (ok), 26-Июн-22, 23:51
	Блин, чувак, в чем твоя проблема? Пролистать гримуар Иртегова по ОС - не так уж сложно, он тонкий. И писан он рунами понятными простым смертным. И даже дух OS/2 оттуда почти не воет, а Призрачный Пингвин приходит всего лишь раз в год, при осознанном вызове, что бы тебе там не говорили гоблины. Для вникания нужно всего лишь 250мл. крови девственной эльфийки - разве это цена, а? Всего три золотых стоит, у нас это на поток уже поставлено. Даже душу продавать уже не надо, как в случае с томом призыва демона Тание н'Баума. Какие только отмазки не придумают эти смерды, лишь бы не образовываться. Заодно не будешь спрашивать глупых вопросов.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	50. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от пох. (?), 27-Июн-22, 09:09
	> Заодно не будешь спрашивать глупых вопросов. Конечно не будет. Сожрет его демон. А защитное построение из трех золотых не сделаешь.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Применение асинхронной буферизированной записи на базе io_ur..."	–1 +/–
	Сообщение от Аноним (-), 27-Июн-22, 23:28
	Ты читал резюме Иртегова? Хрен с горы, который программированием занимался последний раз 20+ лет назад. Лет пять. В каком-то -- хаха -- ЦНИТ НГУ. После чего он попробовал себя в роли админа, решил что это тоже не его, и с тех пор занимается преподаванием. При этом не видно, чтобы у него было бы какое-то теоретическое образование, ни про PhD ни про кандидата наук ни слова. То есть ни практических достижений у него нет, ни академических, но мнение он имеет. И аж целую книгу написал. ... Ты читал что-нибудь кроме Иртегова о создании ОС? Если да, то не мог бы ты вкратце сравнить Иртегова с другими, и поделиться с кворумом своими соображениями, почему Иртегова стоит читать? Если нет, если не читал ничего больше, то не мог бы ты озвучить этот факт? Чтобы мы могли бы со спокойной совестью забыть про Иртегова, как про очередного лашпеда, негодного к системному программированию, и по этой причине подвизающегося на ниве калечения мозгов подрастающим поколениям.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	124. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Dzen Python (ok), 27-Июн-22, 23:52
	Во-воу, полехче. У нас тут и так глобальное потепление намечается, так ты еще и сверху добавляешь температуры. 1. Ну читал, представь себе. Сравнивал. Иртегова могу с лёгким сердцем рекомендовать новичку - вместо мутных статей на лурке от vovan223, мутных правок в педивикии от Hren Sgorovitch'а и настолько же мутных статей от копирайтеров на нонеймовых ресурсах. 2. Ты серьёзно? Гадать по резюме? Нет, стоп, т.е. ты всерьёз так считаешь?
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от пох. (?), 28-Июн-22, 09:39
	> Сравнивал Ну так и в чем принципиальная разница? Ну не бывает, не бывает бюджетной магии. Кольцо продолбали, судя по тому что в эфиопии произошло.  Пентакли не делают из булыжников. Там если не золото, то изумруды, то топазы, то вообще вырезанный из цельного брильянта подавай (понятно, такое только у самого демона и можно выменять...а на что - сам догадайся). P.S. а вообще, наверное, и правда нет уже давно хороших книг. modern operating systems были not-so-modern уже когда книжка писалась.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Dzen Python (ok), 28-Июн-22, 23:11
	От осины не родятся апельсины, а от дуба - армяны. Принципиальная разница? Легкий и понятный язык, без нудных занудствований с жонглированиям терминами, жонглирующими терминами. С примерами реального кода, а не миниксового, который где-то как-то, должен вроде бы как работать. Сравни те же главы про конкурентный доступ к ресурсам у Танненбаума и у Иртегова. Написано одно и то же, в принципе, лайвлок, дедлок, та же теорема о трех философах, только у нашего...проще? понятнее? интуитивнее?, чем у Таниенбаума.
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от tmplsr (?), 01-Июл-22, 18:49
	Арпачи-Дюссо, "Операционные системы: 3 простых элемента" ("Книга Кометы") тоже довольно неплохая, есть перевод от изд-ва ДМК.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Alladin (?), 27-Июн-22, 00:04
	Реально глупый каммент, сказано же начали использовать асинхронные вычисления вместо синхронных... Это значит что вместо блокировок которые предоставляет ядро линукса и многопоток линукса сводится к фиксированному количеству потоков (реальных ядер) и отсутствию синхронных блокировок тоесть даже в однопотоке поток задач бесконечный без переключения контекста..
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	18. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от Alladin (?), 27-Июн-22, 00:14
	со стороны линукса.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от pavlinux (ok), 28-Июн-22, 01:58
	> асинхронные вычисления Это как? Вместо (a+b)^2 , распердоливают на три проца a^2, 2ab и b^2 и потом два раза +? Ну так се оптимизашка.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	148. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от пох. (?), 28-Июн-22, 09:42
	> Это как? Вместо (a+b)^2 , распердоливают на три проца a^2, 2ab и b^2 а учитывая что речь о записи на носитель, у которого "проц" ровно один, очередь одна, iglesia una...ой, не в то окно, то как про машинистку - "такая фигня, такая фигня получается на диске" Одна надежда остается - что memory devices вынесут всю эту братию на свалку истории в ближайшем будущем.
	Ответить | Правка | Наверх | Cообщить модератору

3. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
Сообщение от Шарп (ok), 26-Июн-22, 22:48
Лучше 12309 почините. Позавчера словил при копировании с одного ssd на другой. Сначала выдал скорость 1.7 гбайт/с, а потом комп повис.
Ответить | Правка | Наверх | Cообщить модератору

	6. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (6), 26-Июн-22, 23:04
	так ты, поди, и на репозитарных ядрах сидишь.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (55), 27-Июн-22, 09:24
	Так в рекламных целях Windows устроено? 😊
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (87), 27-Июн-22, 15:24
	Только реклама это ты. Потому что для рекламы не важен контекст, важно постоянное напоминание.
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Применение асинхронной буферизированной записи на базе io_ur..."	+4 +/–
	Сообщение от maximnik0 (?), 26-Июн-22, 23:09
	>выдал скорость 1.7 гбайт/с, а потом комп повис Так 12309 это не зависание а жуткие тормоза с дерганьем мышки ,заикаием звука и т.д Оказался програмно-аппаратной проблеммой,из-за чего долго искали причину.И до сих пор идиотские ошибки всплывают-до пустим 1-2 порты Sata включены в режиме совместимости с ide а 3-4 в ahci.И можно оказываеться словить у многих производителей глюки если диски сидят на 1 и 4 портах и между ними идет обмен.Или комбинация жесткого диска и флэш диска на sata при этом включен Trim.А у меня на ноутбуке при долгом фоновом копирование с внешнего диска и не активности пользователя ноутбук переходил в энергосберегающий режим и внешний юсб диск отключал.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	16. "Применение асинхронной буферизированной записи на базе io_ur..."	–4 +/–
	Сообщение от Alladin (?), 27-Июн-22, 00:13
	Что-то у вас накручено и перекручено.. Если у вас глючит аппарат то ищите обновление биоса, думаю новая прошивка решит этот вопрос. Далее, режим совместимости IDE, а он реально нужен?
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от maximnik0 (?), 27-Июн-22, 04:41
	> Если у вас глючит аппарат то ищите обновление биоса, думаю новая прошивка Этот баг поправили-теперь если нет активности на внешнем диске -отсылает команду перейти в экономный режим,если не переходит отключает питание. > Далее, режим совместимости IDE, а он реально нужен? Сложно сказать но 10 и linux операционки не заканчиваються,вдруг у кого то специфическое оборудование и операционка а драйверов sata нет, режим совместимости спасет.Вон 2 года назат я сперва удевлялся и смеялся,но человеку понадобилось ставить 98 винду на современное железо (дуалбутчик).И к моему стыду человеку подсказали современную материнскую плату с isa портом(сделано через юсб адаптер на уровне биуса)-оказываеться любителями написаны драйвера к pci-e,usb3.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от john_erohin (?), 27-Июн-22, 06:05
	> любителями написаны драйвера к pci-e,usb3. для NT4 где-то были такие драйвера (для SATA тоже). но пользоваться ими я не рискнул. лучше ретрожелезо.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от maximnik0 (?), 27-Июн-22, 10:18
	Ну драйвер к pci-e это скорее затычка,потому что ставилась задача что бы на програмном уровне более менее совместимость была с "старой" pci.А для sata были драйвера от производителей-помню по колледжу с оффициальной лицензионной виндой NT4 sp6a,билд был какой то странный,жалею что копию не снял-интегрирован ie5 с нормальным проводником.Понимала fat32, но дефрагментатора не было,был модернизирован ntfs -совместим от 2000,ставились юсб драйвера для клав,мышек и каких то принтеров и сканеров.Были sata драйвера от intel,sis,via совсем небольшой набор-но видились как scsi диски.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от X86 (ok), 27-Июн-22, 07:41
	Назат удевлялся биуса оказываеться!!!) Заканьчиваться пужалуста!!!
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	22. "Применение асинхронной буферизированной записи на базе io_ur..."	+3 +/–
	Сообщение от Аноним (22), 27-Июн-22, 00:35
	добавь это в /etc/sysctl.conf и 12309 больше тебя не побеспокоит # This fix enoumous big diry bytes (16 gb system vm.dirty_background_bytes 3.2 Gb ??? ) # 64  mb - when system starts writing to disk  64*1024*1024 # 256 mb - when system limits io to device speed 256*1024*1024 # Guys from SUSE recommends keep this in proportion 1:2 - 1:4 # Ubuntu guys recommends to set this even lower 16 and 42 Mb but well... # This emulates near 1 gb ram default behaviour #let only 64 mb of pages in ram before writing to disk on background vm.dirty_bytes = 67108864 #let only 256 mb of pages in ram before blocking i/o to write to disk vm.dirty_background_bytes = 268435456 ## use this on low ram machile (32 and 64 mb) #vm.dirty_bytes = 33554432 #vm.dirty_background_bytes = 67108864
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	28. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от leap42 (ok), 27-Июн-22, 03:46
	Два чаю этому анониму! Ещё можно вот это добавить чтобы данные НЕ терялись (в большинстве случаев, но не всегда конечно) при потере питания: vm.dirty_expire_centisecs = 1000 vm.dirty_writeback_centisecs = 250
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 28-Июн-22, 01:59
	У многих ФС еще настраивается время "барьеров записи". Это время когда форсировано скидывается на диск и фиксируется состояние. Чем реже barrier-ы, тем эффективнее но тем больше данных может быть профакано при слете питания и т.п..
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (80), 27-Июн-22, 14:21
	А почему дистростроители так не поставляют изначально?
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	142. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от leap42 (ok), 28-Июн-22, 03:06
	> А почему дистростроители так не поставляют изначально? Во-первых, дистростроители имеют в виду серверы, где производительность дисковой подсистемы может просесть. Во-вторых, на системах с маленьким количеством памяти может быть странное (впски, микроплатники и т.д.)
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (93), 27-Июн-22, 16:27
	А вы, часом, не перепутали значения для dirty_bytes с dirty_background_bytes?
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	98. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (98), 27-Июн-22, 17:38
	Я вот тоже думаю, у меня vm.dirty_ratio = 10 vm.dirty_background_ratio = 5 ну и kernel.io_delay_type=3, какие ещё делеи?
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от pavlinux (ok), 28-Июн-22, 02:02
	> добавь это в /etc/sysctl.conf и 12309 больше тебя не побеспокоит Предлагаю за копипасту баянов 10-летней давности вводить пожизненный расстрел.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	186. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 29-Июн-22, 22:13
	> Предлагаю за копипасту баянов 10-летней давности вводить пожизненный расстрел. Что, ты тоже в курсе что у них эвристика для тормозных сторажей это сама уже давно делает, а для быстрых это только продолб скорости записи зазря? :)
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Применение асинхронной буферизированной записи на базе io_ur..."	+3 +/–
	Сообщение от Аноним (22), 27-Июн-22, 00:43
	Беда в том что по умолчанию линукс задает размер дискового кэша в % от всей доступной памяти. Когда в ядре это прописывали память измерялась мегабайтами... Сейчаас памяти много, намного больше, кэш получается огромен. В итоге перед реальной записью на диск куча данных пишется в память а потом система пытается всю эту память скинуть на диск... кэш размерами в пару гигабайт... на медленный диск с приоритетом ядра... естественно все начинает тормозить.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	39. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от борланд (?), 27-Июн-22, 06:53
	> Беда в том что по умолчанию линукс задает размер дискового кэша в > % от всей доступной памяти. Когда в ядре это прописывали память > измерялась мегабайтами... Сейчаас памяти много, намного больше, кэш получается огромен. > В итоге перед реальной записью на диск куча данных пишется в память > а потом система пытается всю эту память скинуть на диск... кэш > размерами в пару гигабайт... на медленный диск с приоритетом ядра... естественно > все начинает тормозить. Чому во фре таких пооблем нет и не было? Вся память под кеш юзается тоже.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Анонимленьлогиниться (?), 27-Июн-22, 08:58
	Вам про кэш записи (точнее dirty buffers), а в про кэш чтения )) Под чтение и в линуксе всегда все свободное используется...
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от пох. (?), 27-Июн-22, 09:12
	> Чому во фре таких пооблем нет и не было? тому что у нее вообще нет толком кэширования на запись. vmstat -z и убедись. > Вся память под кеш юзается тоже. Тоже нет. Под мусор разновсяческий - это не под кэш.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	181. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 29-Июн-22, 17:48
	> Чому во фре таких пооблем нет и не было? Вся память под кеш юзается тоже. Ее юзеры для десктопных задач в винду дуалбутятся, вот у них и "нет проблем".
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	60. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от another_one (ok), 27-Июн-22, 10:51
	> Беда в том что по умолчанию линукс задает размер дискового кэша в % от всей доступной памяти. Когда в ядре это прописывали память измерялась мегабайтами... Сейчаас памяти много, намного больше, кэш получается огромен. Чем-то напомнило досовский смартдрайв, который начинал безбожно тормозить, если под кеш выделялось больше 8мб.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	71. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от пох. (?), 27-Июн-22, 13:08
	Беда в том, что с 2.6.13 проблемы не было. А с 2.6.32 на той же, с-ка доступной памяти - откуда-то взялась.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	122. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Ананоним (?), 27-Июн-22, 23:30
	Всё это сказки про кэши. Ошибка в архитектуре. Если бы ядро с X11 дружили бы крепко, то при дисковых операциях никакого глобального лока не было бы, от которого курсор мыши тормозит, а всё работало бы и далее плавно, кроме самого дискового ввода-вывода. Для обработки событий мыши или клавиатуры операции с диском не нужны. И нефиг скидывать в своп системные страницы памяти, задействованные в этом механизме. Выровнять архитектуру просто никому не хочется. Ибо рак щука и лебедь.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Ананоним (?), 27-Июн-22, 23:33
	Могу ещё добавить, что и механизм повышения приоретета для процесса активного окна был бы хорош. Может он есть? Но я сильно сомневаюсь. У меня на 100 процентной загрузке всех 8 потоков видео в браузере тормозит и звук даже заикается. Даже если нагрузку давать через nice.
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от pavlinux (ok), 28-Июн-22, 02:14
	> У меня на 100 процентной загрузке всех 8 потоков видео в браузере тормозит и звук даже заикается. Странно, что не на 146%
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 29-Июн-22, 17:53
	Если на load average смотреть, там и 500% можно получить при достаточном рвении.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от pavlinux (ok), 28-Июн-22, 02:11
	> Беда в том что по умолчанию линукс задает размер дискового кэша В Linux НЕТ ДИСКОВОГО КЭША. Да и дисков уже нет (у нормальных)...
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	57. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (55), 27-Июн-22, 09:26
	Даже пуповину не обрезаем?
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	25. "Применение асинхронной буферизированной записи на базе io_ur..."	+4 +/–
	Сообщение от Анончик (?), 27-Июн-22, 01:17
	я так на usb2 флэшку копирую данные со скоростью в пару гигабит. Потом еще еще 2 часа жду когда оно из буфера скинет на диск ))
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	155. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Ананоним (?), 28-Июн-22, 13:07
	Открой для себя команду sync. Может не придётся 2 часа ждать.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Анончик (?), 28-Июн-22, 18:36
	> Открой для себя команду sync. Может не придётся 2 часа ждать. волшебная комманда которая заставит флэшку быстро работать, супер, спасибо.
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (187), 29-Июн-22, 22:17
	> Открой для себя команду sync. Может не придётся 2 часа ждать. Никогда не видел sync отвисший на 15 минут в именно вот том сисколе? А надо было всего то тормозную флеху с старым кернелом поюзать. Сейчас в новых ядрах так не получится, оно видит что стораж тормоз и лимитирует размер буферов для него. Вместо этого caller начинает ограничиваться в скорости записи, зато не приводит к выжирону всей памяти на буфер и тупняку когда оно кому-то потребовалось а ядро ее м-е-д-л-е-н-н-о в-ы-ж-и-м-а-е-т пока юзер бесится.
	Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

	29. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (29), 27-Июн-22, 03:47
	Попробуй https://www.linux.org.ru/forum/general/16334308/page6
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	40. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Фальсификатор (?), 27-Июн-22, 06:59
	Не хочешь 12309 тогда переходи если это убунта на пониженную версию стабле , а их более новых всего две это 20.04 и 21.04
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	140. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от topin89 (ok), 28-Июн-22, 02:14
	Уверен, что это был именно 12309? У нас регулярно были ситуации, когда по SFTP перекидывались файлы на пару сотен метров, скорость около 20 МБ/с сжатым потоком. И всё висло так сильно, что alt+PrintScreen+B не срабатывало. Залечили отключением режимов сна для NVMe.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

11. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
Сообщение от Dzen Python (ok), 26-Июн-22, 23:45
90% просадок в скорости на ФС дают транзакции и журналирование записи - вообще все то, что делает durty bit если не бессмысленным, то всего лишь некритичным флагом для fsutil пройтись по журналу и поправить ссылки/создать список цепочек блоков в lost+found. Интересно, а ребята тестировали только на грязной стабильной работе, без обработок внештатных ситуаций? Мне вот интересно, как будут восстановлены данные из буфера при некорректном выключении (никак же, да, буфер не сохраняется? Т.е. детская болезнь времен ДОСа возвращается?)
Ответить | Правка | Наверх | Cообщить модератору

	14. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (14), 27-Июн-22, 00:04
	Из буфера памяти? Никак. Иначе какой в нём вообще смысл?
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от Аноним (36), 27-Июн-22, 06:07
	как глубока твоя нора, крол?
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	76. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (87), 27-Июн-22, 13:38
	Этим должен заниматься рейд контроллер в одно лицо.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

20. "Применение асинхронной буферизированной записи на базе io_ur..."	+2 +/–
Сообщение от Аноним (20), 27-Июн-22, 00:28
Пояснительная бригада, теперь XFS лучшая ФС или еще нет?
Ответить | Правка | Наверх | Cообщить модератору

	24. "Применение асинхронной буферизированной записи на базе io_ur..."	–1 +/–
	Сообщение от Анончик (?), 27-Июн-22, 01:12
	нет. Ну там же написано даже по русский асинхронная, далее по тексту тесты приведены где асинхроная запись libaio      так же давала приблизительно такие же результаты.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Применение асинхронной буферизированной записи на базе io_ur..."	–2 +/–
	Сообщение от Аноним (31), 27-Июн-22, 04:02
	Xfs и до этого лучшая фс.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от john_erohin (?), 27-Июн-22, 06:08
	а если опять выкатят новую версию, несовместимую со старой ? 1 раз уже было.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Применение асинхронной буферизированной записи на базе io_ur..."	+5 +/–
	Сообщение от X86 (ok), 27-Июн-22, 07:42
	Тогда освободится место на диске
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от john_erohin (?), 02-Июл-22, 20:31
	зацените по списку: https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.128
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	26. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (98), 27-Июн-22, 01:29
	Нет, у тебя выбор между ext4, f2fs и btrfs сегодня.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	30. "Применение асинхронной буферизированной записи на базе io_ur..."	–4 +/–
	Сообщение от leap42 (ok), 27-Июн-22, 03:48
	lol ext4 в 2022
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (94), 27-Июн-22, 16:38
	Ну в винде до сих пор NTFS и ничо, живут же люди как-то с ней... Зачем чинить то, что не поломалось?
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (31), 27-Июн-22, 04:04
	Выбор сейчас между xfs и f2fs. Причём f2fs сейчас актуальна и для hdd с smr.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	34. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от Попандопала (?), 27-Июн-22, 05:03
	Заяем вам фс для флешек на хдд,ссд?
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Применение асинхронной буферизированной записи на базе io_ur..."	+2 +/–
	Сообщение от Аноним (38), 27-Июн-22, 06:27
	"The motive for F2FS was to build a file system that, from the start, takes into account the characteristics of NAND flash memory-based storage devices (such as solid-state disks, eMMC, and SD cards), which are widely used in computer systems ranging from mobile devices to servers." https://en.wikipedia.org/wiki/F2FS
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от пох. (?), 27-Июн-22, 09:22
	Для _самсунговских_ флэшек, ты забыл уточнить. Поскольку оно "taking in account" не какие-то абстрактные флэшки в вакууме, а сасунг. А для остальных - если ты не угадаешь segment size, то результат будет быстрым и неудивительным. (и нет, для smr дерьмодисков результат в любом случае будет "неудивительным" - f2fs вообще ни разу не про них писалась. С теми единственный возможный способ работы - linear write пока не заполнится, в стиле iso9660. После чего ro lock и на полку.)
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	62. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (62), 27-Июн-22, 11:04
	Че сказать то хотел?
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (95), 27-Июн-22, 17:07
	Короче он так боится фрагментации, что кладёт винчестеры на полку от греха. Ещё б комп не включал, и было бы ваше ништяк.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 27-Июн-22, 18:31
	> Для _самсунговских_ флэшек, ты забыл уточнить. Флешки все более-менее одинаковые. И у самсуня их так то много разных есть. Самсунг там ничего такого не изобрел. Совсем. Даже JEDEC-у какому поди соответствуют и такие же чипы 1 в 1 у еще эн вендоров будут. С таким же объемом и размером блоков. Поэтому F2FS довольно прилично по скорости работает на флешатине. Но вот только при power loss может фатально развалиться, да так что fsck не чинится :) А что до SMR - это для них Zoned пилят в btrfs как я понимаю.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	125. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от пох. (?), 28-Июн-22, 00:14
	А "более-менее" тут не работает. Либо ты попал в segment size, либо write amplification в хз сколько раз (в зависимости от того, какой там размер страницы и куда ты угодил сегментом) Кстати, скорее всего на родном флэше так и не разваливается именно по этой же причине. > А что до SMR - это для них Zoned пилят в btrfs как я понимаю. да для них что ни пили - все п-ц. iso9660 только вот если. Идея в том, что метаинформацию надо где-то хранить. Даже в самой супер-COW fs - все равно есть нечто где лежит указатель на все остальное дерево,и это нечто фиксированное на диске. И его надо менять с каждой новой транзакцией. Для smr диска это означает переписывание всей чешуи по нескольку раз. Авторы технологии cd-r решили эту проблему понятным образом - достоверная информация всегда в последних секторах последнего трека, который даже без помощи аппаратуры (которая предоставлена) легко определяется как "дальше - ничего нет". Вот эта метода будет работать с smr без кабздеца с write multiplication в двести раз. Но ты такой fs не захочешь, наверное. Для host-managed возможно еще что-то сделать за счет cmr зоны, если на нее, конечно, не пожабились. А для типового ширпотреба ничего лучшего ты не придумаешь.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 28-Июн-22, 01:56
	> А "более-менее" тут не работает. Либо ты попал в segment size, либо write amplification > в хз сколько раз (в зависимости от того, какой там размер страницы и куда ты угодил сегментом) У NAND так то есть eraseblock, и page. Первое юнит "erase" и довольно жирное, а второе "program", и размером несколько кило. Кто из них "сегмент"? У F2FS общая структура и логика записей такая что оно всему этому не особо враждебно. А идеально угадать все-равно не получается, поди tot убеди программы писать только кратно 2^N. Так что в среднем он недурно работает на флеше, особенно low end, типа флешек и карточек памяти. На SSDшнике - в принципе тоже, но смысла меньше уже. > Вот эта метода будет работать с smr без кабздеца с write multiplication в двести раз. > Но ты такой fs не захочешь, наверное. Btrfs'ники явно обошли это дело. Они просто дописывают в зону, иногда GC делают. По сути это напоминает FTL в флешовых девайсах немного. Если они еще и bad blocks management сделают, смогут вообше на RAW NAND работать пожалуй :). Но врядли они это захотят кодить, mtd штука специфичная. И да как я понимаю zoned у них ориентируется на то что хост этим рулит. Поэтому оно там радикально меняет логику аллокации, группируя все в длинные непрерывные сегменты. Такое и на флеш в принципе хорошо ложится, даже если не идеально угадали.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от пох. (?), 28-Июн-22, 09:56
	> У NAND так то есть eraseblock, и page. Первое юнит "erase" и довольно жирное, а второе > "program", и размером несколько кило. Кто из них "сегмент"? по дефолтным настройкам самсунь-fs - они целились в page size. И, вероятно, попали - для своих флэшек про которые точно знали каким он может быть (а теперь - знают что флэшка в телефоне и шибкоумном телевизоре будет использована этой fs, и уже под нее подгоняют дизигн) - и там еще какие-то костылики чтоб не промазать мимо границы. Было бы странно наоборот. > Btrfs'ники явно обошли это дело. Они просто дописывают в зону так дописывать-то тоже нельзя. ^^^^........... ^^^^^^^^.......   ^^^^^^^^^...... Вот при попытке дописать куда-то кроме последнего шингла - причем с твердым знанием что оно вот так на диске и терять в двух верхних нечего - ты идешь переписывать все. А там по паре гигабайт даже у устаревших немодных 6T, и слоев этих не три ни разу. Мне казалось они там не о h-smr думали вовсе, а о просто "больших" с вынесенным в хост знанием о различии внешних и внутренних частей или флэшах с двойной начинкой slc/mlc. А пока они все это думали, такие диски вышли из моды - это было популярно лет семь назад, до засилия smr'ок.
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 29-Июн-22, 18:18
	> по дефолтным настройкам самсунь-fs - они целились в page size. И, вероятно, > попали - для своих флэшек про которые точно знали каким он может быть Самсунь производит чертову кучу флешек, всех мастей и направлений, которым из они удобно сделали? А то их там легион на все вкусы, вон те купят такие, а эти эдакие, а продажи в результате растут :). Что можно было стандартизировать JEDEC стандартизировал. ЧСХ, размеры page и erase block для типичных флех у самса такие же как у конкурентов для сравнимого объема и технологии, плюс-минус лапоть. Ну то-есть они там обезьянят друг у друга, и когда кто-то увеличивает размер страницы, остальные быстро понимают что и им пора - это эффективнее по площади кристалла vs доступный юзеру объем: FEC для длинных блоков в целом лучше по % оверхеда. А с учетом хлипкоты MLC на тонких нанометрах суровый FEC там очень больной топик. А еще перед нандом на котором F2FS - контроллер с FTL, совсем не факт что самсовский. И он свое мнение в своей фирмвари имеет как он там геометрию флеша абстрагирует. Наверняка чертова куча самсовского флеша паяется с не самсуневыми контроллерами в паре. Самый очевидный фокус который они делают это interleave. Но бывает много чего еще, сжатие и дедуп, даже подпертые хардваром. > (а теперь - знают что флэшка в телефоне и шибкоумном телевизоре будет > использована этой fs, и уже под нее подгоняют дизигн) - и там еще > какие-то костылики чтоб не промазать мимо границы. Так, блин, телефонов и телевизоров - и флешек в них легион, а на момент выкладывания f2fs самые типовые еще и другие были. В любом случае, их механика в целом к флешу дружелюбна. Посмотри бенчи на форониксе, те гоняли это на самых разных устройствах вплоть до SSD (хоть она и не для этого, скорее для eMMC/uSD/тому подобного). Если флеш не тормозит - значит ему удобно и нет сильной амплификации. > Было бы странно наоборот. Так можно сказочно прострелить себе пятки. > так дописывать-то тоже нельзя. Они группируют записи в большие регионы и пишут целиком регионы как я понимаю. Иногда делая GC таких блоков. Кроме всего прочего FTL то же самое с eraseblock'ами на флеше делает. Там битики только в одну сторону по мелкому можно перетягивать, в другую только стиранием огромного блока. > верхних нечего - ты идешь переписывать все. А там по паре > гигабайт даже у устаревших немодных 6T, и слоев этих не три ни разу. Btrfs при этом пишет НОВЫЙ блок, он же CoW, ему это как дом родной. А неиспользуемые блоки или блоки где осталось мало актуальных данных шедулятся для GC. Очень FTL напоминает, осталось разве что RAW NAND на MTD научить менеджить, но кмк они не настолько мазохисты :) > Мне казалось они там не о h-smr думали вовсе, Судя по свежему commit'у от чувака с @wdc.com с логом где девайс лупанул io error - "UNALIGNED WRITE" - таки видимо про них? А прикольно, WDшники же и кодят поддержку своих девайсов.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (146), 28-Июн-22, 08:57
	нее, smr ремапят на лету, куда голову ближе подогнать, туда и пишут, поэтому даже на iso9660 не тянут, и на ленту не тянут... фрагментируют даже на единичной последовательной записи... пруф уже не найду сечас...
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	47. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Анончик (?), 27-Июн-22, 08:25
	в f2fs есть квоты? или как вы предлагаете рулить местом?
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	54. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от пох. (?), 27-Июн-22, 09:24
	Вообще-то есть, но они тоже "удивительные". С другой стороны - у меня нет никаких квот ни на одной системе. Зачем мне самому себе раскладывать грабли?
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (87), 27-Июн-22, 13:36
	Так смысл их раскладывать для других, а не для себя.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Роман (??), 27-Июн-22, 13:40
	Я вот кроме как для шаред хостингов не могу придумать зачем оно по факту надо - можете кейсов интересных накидать? В своей практике кажется лет 15 квоты уже не использовал.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от пох. (?), 27-Июн-22, 15:21
	> Я вот кроме как для шаред хостингов не могу придумать зачем оно по факту надо VDI же ж. Но там, как ты понимаешь, не linoops (не совсем во всяком случае), и лимиты эти не на физическом диске а на smb share. (Правда, есть мнение что сосамба ниочинь работает с f2fs, а вот для xfs у нее есть плагин, пропускающий половину ненужного копирования из одного буфера в соседний)
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (126), 28-Июн-22, 00:16
	Для каких «других»? На моём ПК нет никаких «других».
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	63. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (98), 27-Июн-22, 11:05
	Это хорошо, когда люди сообщают такое, сразу можно оценить степень их адекватности.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	66. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от Аноним (65), 27-Июн-22, 11:13
	Ненужный УГ кусов, который проталкивает Бизнес Машина, чтобы было не как у всех.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	103. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 27-Июн-22, 18:24
	А что делать, другие уже конкуренты расхватали. И это таки именно редгадчики, профакавшие спецов блочного уровня. А если они такие крутые, пусть честно скажут сколько IOPSов в удалении цатигиговых фрагментированых файлов их нечто могет изобразить :)
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Применение асинхронной буферизированной записи на базе io_ur..."	–1 +/–
	Сообщение от Аноним (93), 27-Июн-22, 15:47
	Если нет необходимости в компрессии, xfs - по совокупности пот.характеристик, лучшая файловая система. Даже до этих патчей...
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	104. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 27-Июн-22, 18:26
	Чего в нем хорошего? Кроме того что у редгада просто ничего другого не осталось, не JFS же им было брать?! А все эти md, dm, lvm и проч - таки масдай, вместе с сратисом.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от лютый жабби___ (?), 27-Июн-22, 19:27
	>теперь XFS лучшая ФС или еще нет монговцы её уже много лет самой быстрой считают. а уж они-то не могут ошибаться
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	114. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (114), 27-Июн-22, 20:19
	>Пояснительная бригада, теперь XFS лучшая ФС или еще нет? Ещё нет. Отрицательный ресайз ещё не сделали, хранение мелких файлов прямо в нодах.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	127. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (127), 28-Июн-22, 00:57
	> Отрицательный ресайз Настолько нишевая штука, что может быть вообще никогда не появится, если только не окажется так, что её можно реализовать «бесплатно». Сам-то можешь придумать кейс для прода, когда это востребовано? У меня фантазии не хватает.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 28-Июн-22, 02:02
	> Настолько нишевая штука, что может быть вообще никогда не появится, если только > не окажется так, что её можно реализовать «бесплатно». Сам-то можешь придумать > кейс для прода, когда это востребовано? У меня фантазии не хватает. Вынуть диск, в случае если столько стало уже не надо, например. И более того - ничему не противоречит разово расширить хранилку для какой-то разовой операции, а завершив ее... ну и зачем нам там в 2 раза больше дисков чем реально надо? А ну да, удобное и эффективное управление - это не про редгадов.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от пох. (?), 28-Июн-22, 10:02
	> Вынуть диск, в случае если столько стало уже не надо, например. цена вопроса - безумная деградация производительности, пока твое "не надо" освобождается. Возможно еще и с риском получить полную катастрофу при сбое во время этой операции. Поэтому для всех кроме одичалых, у которых дисков больше не будет, проще плюнуть и оставить тот диск в массиве. > ну и зачем нам там в 2 раза больше дисков чем реально надо? затем что он уже установлен и размечен - и проще и дешевле его и дальше использовать, хотя бы для распараллеливания доступов. А поскольку есть thin-lvm и discard, мы всегда можем на освободившейся части создать еще одну fs, если нам хочется отделить мух от котлет - это действительно бесплатно (ок, почти).
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 29-Июн-22, 22:28
	> цена вопроса - безумная деградация производительности, пока твое "не надо" освобождается. 1) Не хуже ребилдов райда и проч. 2) Оно удвигает только реально используемое. 3) Это все же не такая уж частая операция. > Возможно еще и с риском получить полную катастрофу при сбое во время этой операции. В силу CoW'ания это довольно маловероятно. Оно сперва заканчивает операцию, ПОТОМ "апдейтит указатели". Физически данные на том носителе не уничтожаются, так что даже если "апдейт указателей" не прошел, это как минимум читаемо должно остаться. А еще оно знает какая копия где верная, за счет чексум. И может повторить чтение проблемного блока с другой копии. В сочетании с двиганием только реально занятого ... оно вроде не такое уж и стремное и заканчивается обычно быстрее чем этого можно ожидать. > Поэтому для всех кроме одичалых, у которых дисков больше не будет, проще > плюнуть и оставить тот диск в массиве. Может я добавлял еще эн дисков чтобы временно расширить для какой-то разовой большой кантовки? И уверен что это разовая операция, так что те эн дисков потом там нахрен не надо. > затем что он уже установлен и размечен - и проще и дешевле > его и дальше использовать, хотя бы для распараллеливания доступов. В каком месте докупать диски в случае когда модно было воткнуть эти - дешевле? > А поскольку есть thin-lvm и discard, мы всегда можем на освободившейся части > создать еще одну fs, если нам хочется отделить мух от котлет > - это действительно бесплатно (ок, почти). Ух, спасибо, сам этим всем пользуйся. И вот там если что-то развалится удачи тебе с саппортом редхата. Ты еще в РФ? Если да, ты получаешь +2 к удаче в их саппорте, ага.
	Ответить | Правка | Наверх | Cообщить модератору

	191. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от пох. (?), 29-Июн-22, 23:01
	>> цена вопроса - безумная деградация производительности, пока твое "не надо" освобождается. > 1) Не хуже ребилдов райда и проч. рейд в 2k22 немодно. ребилды raidz или storage space ТАК не жрут, поскольку затрагивают только один диск на запись, а не весь массив. > 2) Оно удвигает только реально используемое. ну и кому это поможет? > 3) Это все же не такая уж частая операция. поэтому без нее можно и пережить >> Возможно еще и с риском получить полную катастрофу при сбое во время этой операции. > В силу CoW'ания это довольно маловероятно. Оно сперва заканчивает операцию, ПОТОМ "апдейтит так там нет никакого cow. Там апдейтятся корневые структуры описывающие саму структуру носителей. В куче разных мест и ни разу не атомарно - диски такого не умеют. > указатели". Физически данные на том носителе не уничтожаются, так что даже но вернуться в прошлое будет нетривиально. > Может я добавлял еще эн дисков чтобы временно расширить для какой-то разовой > большой кантовки? И уверен что это разовая операция, так что те > эн дисков потом там нахрен не надо. ну вот что-то мне подсказывает что никто так в реальной жизни не делает. > Ух, спасибо, сам этим всем пользуйся. И вот там если что-то развалится Вот там - не развалится. А тут - поскольку двавасяна&co ляпали для каких-то своих васянских задач - очень даже может.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (170), 29-Июн-22, 02:15
	Я просил кейс для прода, а не из, кхм, пальца высосанный.
	Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

	185. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 29-Июн-22, 18:24
	> Я просил кейс для прода, а не из, кхм, пальца высосанный. Вполне нормальный кейс, расщирить имеющуюся хранилку под какую-то разовую пиковую задачу, а потом вынуть это нафиг куда-то где оно нужнее, если понятно что эта хранилка больше настолько не будет забита в обозримом будущем.
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от пох. (?), 29-Июн-22, 23:03
	>> Я просил кейс для прода, а не из, кхм, пальца высосанный. > Вполне нормальный кейс, расщирить имеющуюся хранилку под какую-то разовую пиковую задачу, > а потом вынуть это нафиг куда-то где оно нужнее, если понятно с риском потерять всю хранилку если что-то пойдет не так. Ну ок, "нормальный кейс" для этих вот - "вебторрент, блокчейн, деньги из воздуха". Но xfs немного на другую целевую аудиторию нацелена, та - не очень страдает.
	Ответить | Правка | Наверх | Cообщить модератору

52. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
Сообщение от Аноним (52), 27-Июн-22, 09:17
и сделало 80 каких-нить уязвимостей которые найдут через пять лет
Ответить | Правка | Наверх | Cообщить модератору

	56. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от пох. (?), 27-Июн-22, 09:24
	Вот видишь - целых пять лет твоя дыра - в безопастности!
	Ответить | Правка | Наверх | Cообщить модератору

61. "Применение асинхронной буферизированной записи на базе io_ur..."	–1 +/–
Сообщение от Аноним (61), 27-Июн-22, 11:01
Херасе они кэш изобрели!!! Срочная новость "Виндекапец близко"
Ответить | Правка | Наверх | Cообщить модератору

	106. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 27-Июн-22, 18:33
	Ты тормоз, Вася.
	Ответить | Правка | Наверх | Cообщить модератору

72. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
Сообщение от freehck (ok), 27-Июн-22, 13:15
> Предварительные тесты производительности, проведённые при помощи инструментария fio (1 поток, размер блока 4кб, 600 секунд, последовательная запись), показывают увеличение числа операция ввода/вывода в секунду (IOPS) от 77k до 209k, скорости передачи данных от 314MB/s до 854MB/s и падения задержек от 9600ns до 120ns (80 раз). Ну если это всё правда, то тогда надо сделать новые бенчмарки для сравнения с ext4. Если раньше ext4 отставала процентов на 5-8 в разных тестах, то с этими данными, вероятно, у нас появится новая дефолтная ФС.
Ответить | Правка | Наверх | Cообщить модератору

	73. "Применение асинхронной буферизированной записи на базе io_ur..."	+3 +/–
	Сообщение от Аноним (87), 27-Июн-22, 13:35
	XFS итак дефолтная файловая система кое-где.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Роман (??), 27-Июн-22, 13:41
	Ext4 вроде на очереди на поддержку io_uring
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	82. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от ананоша (?), 27-Июн-22, 14:51
	Btrfs
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 27-Июн-22, 18:34
	Всех живых на него наверное перетянут. А кто не перелезет станет постепенно считаться легаси. Приветы шишкинфсам, игнорьте новые клевые апи дальше, так из ядра и улетите.
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	116. "Применение асинхронной буферизированной записи на базе io_ur..."	–1 +/–
	Сообщение от Аноним (114), 27-Июн-22, 20:25
	Reiser5 с большой вероятностью это io_uring задействует. А в ядро она и так не попадёт, впрочем, как и ZFS.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 28-Июн-22, 01:43
	Агаблин, зная их методики - они это сделают когда в ядре дропнут к хренам легаси апи (и всех кто не раздуплился перейти на новое внутриядерное апи, ибо трупы надо иногда выносить). Через полгодика кодинга в режиме "подгорело - фс не работает". Майнтайнеры линуха догаываются о таких соотношениях еще на подлете и ключевая причина почему ее там не будет на самом деле - вот эта.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (176), 29-Июн-22, 12:51
	Тебе мысли излагать научиться бы.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от rationalseed (?), 03-Июл-22, 21:04
	А где тут видна мысль? Какой-то шум дождя....
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (93), 27-Июн-22, 15:34
	У ext4 проблемы иного характера - с масштабирование.
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

83. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
Сообщение от Аноним (-), 27-Июн-22, 14:52
А на чём проверяли? Cкорости которые описаны похожи на скорсти от NVMe. Это рам диск ddr3 1333Hz два канала fat32 кластер 4Кб: ------------------------------------------------------------------------------ CrystalDiskMark 8.0.4 x86 (C) 2007-2021 hiyohiyo                                   Crystal Dew World: https://crystalmark.info/ ------------------------------------------------------------------------------ * MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s] * KB = 1000 bytes, KiB = 1024 bytes [Read]   SEQ    4KiB (Q=  8, T= 1):   166.137 MB/s [  40560.8 IOPS] <   170.89 us>   SEQ    4KiB (Q=  1, T= 1):   195.756 MB/s [  47792.0 IOPS] <    18.46 us>   RND    4KiB (Q= 32, T= 1):   161.623 MB/s [  39458.7 IOPS] <   783.15 us>   RND    4KiB (Q=  1, T= 1):   191.221 MB/s [  46684.8 IOPS] <    18.45 us> [Write]   SEQ    4KiB (Q=  8, T= 1):   137.327 MB/s [  33527.1 IOPS] <   207.03 us>   SEQ    4KiB (Q=  1, T= 1):   140.372 MB/s [  34270.5 IOPS] <    26.65 us>   RND    4KiB (Q= 32, T= 1):   133.575 MB/s [  32611.1 IOPS] <   947.88 us>   RND    4KiB (Q=  1, T= 1):   139.039 MB/s [  33945.1 IOPS] <    26.55 us> Profile: Default    Test: 1 GiB (x5) [Z: 0% (0/3019MiB)]    Mode: [Admin]    Time: Measure 5 sec / Interval 5 sec    Date: 2022/06/27 9:11:42 То есть еслибы я мог в Linux создать рам диск как устройство NVMe и отфармотировать в xfs в Linux, и запустить тест KDiskMark (fio) то молучил с этим пачем прирост скорости в три раза? У меня сомнения что-то я не понемаю до конца. Нет информации на каком оборудовании получили прирост. А c остальными устройствами тоже прирост в три раза usb, hdd, DVD-R? DVD-R это сарказм. ------------------------------------------------------------------------------ CrystalDiskMark 8.0.4 x86 (C) 2007-2021 hiyohiyo                                   Crystal Dew World: https://crystalmark.info/ ------------------------------------------------------------------------------ * MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s] * KB = 1000 bytes, KiB = 1024 bytes [Read]   SEQ    1MiB (Q=  8, T= 1):  1851.487 MB/s [   1765.7 IOPS] <  3953.91 us>   SEQ    1MiB (Q=  1, T= 1):  2041.897 MB/s [   1947.3 IOPS] <   504.95 us>   RND    4KiB (Q= 32, T= 1):   161.623 MB/s [  39458.7 IOPS] <   783.15 us>   RND    4KiB (Q=  1, T= 1):   191.221 MB/s [  46684.8 IOPS] <    18.45 us> [Write]   SEQ    1MiB (Q=  8, T= 1):  1971.909 MB/s [   1880.6 IOPS] <  3700.51 us>   SEQ    1MiB (Q=  1, T= 1):  1996.254 MB/s [   1903.8 IOPS] <   516.41 us>   RND    4KiB (Q= 32, T= 1):   133.575 MB/s [  32611.1 IOPS] <   947.88 us>   RND    4KiB (Q=  1, T= 1):   139.039 MB/s [  33945.1 IOPS] <    26.55 us> Profile: Default    Test: 1 GiB (x5) [Z: 0% (0/3019MiB)]    Mode: [Admin]    Time: Measure 5 sec / Interval 5 sec    Date: 2022/06/27 9:24:56
Ответить | Правка | Наверх | Cообщить модератору

	91. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 27-Июн-22, 15:56
	Забыл у KDiskMark ограничение в настройках для SEQ, нет варианта для SEQ ниже 1МиБ. Ладно fio через консоль.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 27-Июн-22, 22:36
	1333МHz
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	119. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 27-Июн-22, 22:50
	Я не правильно написал. Не 1333Мгц, а 667Мгц. Стандартное название  | Частота памяти, МГц | Время цикла, нс | Эффективная скорость, млн передач/с | Название модуля | Пиковая скорость передачи данных при 64-битной шине данных в одноканальном режиме, МБайт/с DDR3‑800     100     10,00     400     800     PC3‑6400     6400 DDR3‑1066     133     7,50     533     1066     PC3‑8500     8533 DDR3‑1333     166     6,00     667     1333     PC3‑10600     10667 DDR3‑1600     200     5,00     800     1600     PC3‑12800     12800 DDR3‑1866     233     4,29     933     1866     PC3‑14900     14933 DDR3‑2133     266     3,75     1066     2133     PC3‑17000     17066 DDR3‑2400     300     3,33     1200     2400     PC3‑19200     19200
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	120. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 27-Июн-22, 22:55
	Пропустил название Частота шины, МГц для 400     533     667     800     933     1066     1200
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Анонним (?), 28-Июн-22, 18:21
	Посмотрим как это в виртуальной машине будет работать с хостом Windows. Я посмотрю, мне это надо.
	Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

88. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
Сообщение от Аноним (93), 27-Июн-22, 15:32
Я правильно понимаю, они sync-write делают async?
Ответить | Правка | Наверх | Cообщить модератору

	158. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от zensey (ok), 28-Июн-22, 16:09
	Нет, просто добавили поддерку API io_uring. В этом API есть средства синхронизации.
	Ответить | Правка | Наверх | Cообщить модератору

109. "Применение асинхронной буферизированной записи на базе io_ur..."	–3 +/–
Сообщение от Аноним (109), 27-Июн-22, 18:49
XFS же deprecated. Разве нет?
Ответить | Правка | Наверх | Cообщить модератору

	113. "Применение асинхронной буферизированной записи на базе io_ur..."	+1 +/–
	Сообщение от anonymous (??), 27-Июн-22, 19:49
	хороший наброс, годный
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Аноним (-), 28-Июн-22, 01:46
	Вообще, есть и deprecated версия оного. Они новую версию запилили, при том - не совместимо со старой. И без конверсии онлайн. Офигенно просто. Про старую кернел трындит что в 2030 будет дропнуто, чтобы не расслаблялись, ага. А единственным способом конверсии является "заново пересоздать" походу. Можно оценить все прелести менеджмента файлух в стиле редгада.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от pda (ok), 28-Июн-22, 11:57
	Если до 2030, то и конвертацию могут запилить.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Применение асинхронной буферизированной записи на базе io_ur..."	+/–
	Сообщение от Попандопала (?), 28-Июн-22, 14:10
	Никто этого не будет теперь делать и никто не оплатит энтузиастов если такие найдутся. Дропнули обозвав легаси в стиле Айпони  и на этом можно успокоиться. Третий рейзер тоже собрались к 2025 году выкинуть. Кругом печалька. На УФС2 перебираться буду когда отважусь к 2025.D ЗФС для хомячкого локалхоста излишен.
	Ответить | Правка | Наверх | Cообщить модератору

172. "Применение асинхронной буферизированной записи на базе io_ur..."	+3 +/–
Сообщение от vitalif (ok), 29-Июн-22, 02:21
Новость из серии "учёный изнасиловал журналиста". Поддержка асинхронной буферизированной записи в io_uring для XFS уже была, и для ext4 уже была. Её для XFS просто ускорили - добавили "fast path". 99% приложений это ни холодно, ни жарко, ибо те, кто морочится об асинхронной записи, в основном работают без буферизации, с O_DIRECT, в частности, потому, что в linux aio асинхронная запись просто не работает без O_DIRECT - она превращается в синхронную. В io_uring вот работает, да, но кто ж его поддержал-то... Кроме того, если пройти по ссылке на первоисточник, там видно, что и большой прирост в довольно специфическом кейсе...
Ответить | Правка | Наверх | Cообщить модератору

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

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