The OpenNET Project / Index page

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



"Применение асинхронной буферизированной записи на базе io_uring до 80 раз снизило задержки в XFS "
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Присылайте удачные настройки в раздел примеров файлов конфигурации на WIKI.opennet.ru.
. "Применение асинхронной буферизированной записи на базе 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ообщить модератору

Оглавление
Применение асинхронной буферизированной записи на базе io_uring до 80 раз снизило задержки в XFS , opennews, 26-Июн-22, 22:47  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



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

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