LINUX.ORG.RU

DAXFS — новейшая высокоскоростная ФС

 , ,


0

2

DAXFS — это простая файловая система только для чтения, которая работает непосредственно с общей физической памятью через подсистему DAX (Direct Access). Она полностью обходит традиционный стек блочного ввода-вывода, чтение файлов осуществляется путем прямой загрузки в память без кэша страниц и копирования.

Особенности:

  • чтение файлов происходит как прямая загрузка из памяти, без дублирования в кэше;
  • поддержка памяти GPU, FPGA и CXL-устройств через DMA;
  • DAXFS изначально был разработан для многоядерных сред, где несколько экземпляров ядра совместно используют одну область физической памяти;
  • использует формат образа только для чтения, не требующий выделения памяти во время выполнения и сложного управления устройствами.

Предложение отправлено в Linux Kernel Mailing List. Код уже доступен на GitHub, но для включения в основное ядро Linux потребуются обсуждения и доработки.

>>> Phoronix

★★★★★

Проверено: cetjs2 ()
Последнее исправление: hobbit (всего исправлений: 6)
Ответ на: комментарий от monk

да, это последствия ущербного подхода недо-вм, хотя они даже до уровня openvz не дотягивают. ИЧСХ, у него как раз такой проблемы не было.

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

Если данные размещаются в памяти, более того размещаются определенной программой в определенных условиях, без r\w - какой смысл дергать для их чтения блочные функции, если можно обращаться напрямую по указателю?

Например, потому что уже есть программа, распространяемая в виде образа докера, которую надо запускать во множестве экземпляров. И выбор как всегда: костыль или велосипед. Костыль мы обсуждаем сейчас, а велосипед = собственная программа, делающая то же самое, но использующая разделяемую память для данных вместо файлов.

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

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

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

Исошник, не исошник... Во тут коллеги накидали пару кейсов, может чего и получится. Но применительно к контейнерам (читай — исошникам) тут толку мало. Вот применительно к read-only кешам или к большим словарям для параллельных вычислений может выйгрыш какой и будет.

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

Дайте грант, и я создам write-only filesystem, по скорости опережающую вообще всех.

> /dev/null уже изобрели, вы опоздали.

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

Несомненно.

Вообще именно ФС такую на FUSE тоже сделать очень легко (наверняка даже есть уже, но я не проверял).

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

Блочные функции как ни странно тоже для своей работы требуют стек

Только не удивляйся, но всё что работает через ядро требует стек. А любая файловая система в общем то внезапно тоже работает через ядро. Не, ну конечно можно придумать какое-нибудь приседание вокруг всяких там новомодных механизмов типа spdk и тому подобных, но там лекарство как бы не хуже болезни.

Получается если у меня есть 16 гиговый файл в ОЗУ, и мне нужно его с’fread’ить - то мне будут нужны еще 16 гиг ОЗУ, ну либо же костыли с поблочным чтением.

Функция fread построена так, что читает в юзерспейсный буфер. Поэтому все программы которым используют эту функцию требют «еще 16 гиг» как ты написал. А вот чтобы ходить в ту же память в которой лежит файл - всё, внезапно, уже придумано - и зовется… Эмм, как оно звалось?! Точно - зовется mmap. У тебя файл на tmpfs, ты делаешь mmap и потом можешь с этим файлом работать как будто он уже загружен в память. Нафига для этого придумывать новую ФС?

По факту это такая упрощенная (но не факт, ибо например всякие xattr, сим и хард линки и прочее никто не отменял) iso9660 поверх ramdisk, только «всё в одном»

no-dashi-v2 ★★★★
()
Ответ на: комментарий от MKuznetsov

Насколько я понимаю, обход страничного кэша позволяет экономить память на системах с несколькими ядрами. А вы видели сколько память нынче стоит?

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

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

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

Большой файл налитый в память для обхода кешей ничего не экономит а как раз наоборот. (зато его «хакать» просто, нашёл адрес и раздал зловреда на все ядра без лишних следов)

Единственный разумный вариант, это если файл УЖЕ в памяти by-design и read-only он тоже аппаратно.. ROM, GPU, модные NN-ускорители, может ещё что-то подобное. Только зачем там целая файловая система

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

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

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

В vz изрядное приседалово вприсядку было для того, чтобы расшарить между паравиртуалками общие файлы. На хостовой ноде распаковывались особым образом приготовленные пакеты, файлы которых потом пробрасывались в ВМ с COW-семантикой. Деталей, конечно, уже не помню, всё ж таки двадцать лет прошло, но Интересных Технических Решений было порядком.

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

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

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

Твоего разрешения никто и не спрашивал, успокойся, бггг.

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

Чтобы оттуда что-то прочитать туда надо что-то записать, а фс только для чтения

Чтобы продать что-нибудь нинужное нужно купить что-нибудь ненужное, а у нас денег нет :)

pihter ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.