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

жду с нетерпением

А если файл из этой ФС заммапить (или что-то подобное), то получится прямой доступ к памяти, как к разделяемой памяти?

И почему бы не сделать возможность писать в файлы (хотя бы и без изменения размера).

Сюда лучшую фс в мире))!

файловая система только для чтения

Не понял.

Какое из слов вызывает проблемы?

Какой смысл в этой ФС, если она только для чтения?

По ссылке на гитхабе написано, для чего её изначально разрабатывали:

DAXFS was originally designed for multikernel environments, where multiple kernel instances share a single physical memory region. The primary use case was booting Docker images: a daxfs image of a container rootfs placed in shared memory provides all kernels with a common read-only filesystem without any inter-kernel communication or network I/O.

Для тебя концепция read-only FS в принципе что ли нова? Эта далеко не первая и не последняя.

Для тебя концепция read-only FS в принципе что ли нова?

Ну CD-ROM знаю.

Ясно.

В общем, это не для тебя, проходи мимо ;)

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

ну создают образы и так далее же.

Не понял.

как книжка - купил и читай.
а хочешь писать - купи себе блокнот

Ага, и это называется WORM.

А хочешь писать - есть поля.

Убийца squashfs? Не думал что можно придумать что-то более крутое для подобного применения

Убийца squashfs?

Не. Тут компрессии нет, и из оперативы работает. Другой принцип и юзкейсы. Хотя есть, наверное, перекрывающиеся.

Тут компрессии нет, и из оперативы работает. Другой принцип и юзкейсы.

Хм. Убийца ramfs/tmpfs?

Хм. Убийца ramfs/tmpfs?

Тоже не совсем. Тут ro, а там rw. Но опять же, для какой-то части юзкейсов — возможно.

Боже, останови нейросети !

Выходит, squashfs и все сд ДВД Ромы тоже не нужны?

Ниша?

А что там с правами, атрибутами и прочим? Можно ли использовать для корня или ещё каких файловых данных только для чтения вместо ext234 или xfs?

почему бы не сделать возможность писать

Тогда надо придумать какой-то механизм блокировки или синхронизации. Иначе прикладное ПО рано или поздно обязательно испортит себе данные, как в той истрии с O_DIRECT и софтовым RAID.

в пару к ней ещё write-only-filesystem. /dev/null на максималках :-)

кроме шуток, даже на целевом юз-кейс «подлючать докеры» существенного выигрыша кроме поломки «обходит традиционный стек блочного ввода-вывода» НЕТ. Может несколько процентов на специально подобранных тестах.

Главное как вайленд/системд, реализовать окно овертона «слом работающих традиций» и начало разброда ещё и там. То есть в ядро оно гарантированно попадёт

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

А хочешь писать - есть поля.

В подъездах теплее

Тогда, может быть, это конкурент TernFS?

TernFS предназначена для распределённого хранения крупных неизменяемых файлов — как правило, они не редактируются после создания и имеют размер от нескольких мегабайт.

Ну вот это и удивляет. Одну книжку пятеро одновременно не читают :)

Тогда надо придумать какой-то механизм блокировки или синхронизации

зачем что-то придумывать? всё давно уже есть

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

на книжке хоть пометки можно сделать госпаде

DAXFS -- новейшая высокоскоростная ФС (комментарий)

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

прочитал голосом Матроскина!
лучше даже так:
чтобы оттуда что-то прочитать, надо сначала туда что-то записать, а у нас файлов нет!

FPGA и CXL-устройств через DMA

примерно понятно откуда ноги растут.
в FPGA пишется при производстве и при старте оборудования или перезаливки туда конфига. далее - это условно-постоянная инфа.

и кэш тут даже вредит.

голосом Бывалого: всё уже записано до нас!

Спасибо, я прочел. А вот теперь опиши мне юзкейс одновременного прочтения одного исошника десятью приложениями.

а где ты увидел там слово «ISO»? ;-)

ну и DAXFS -- новейшая высокоскоростная ФС (комментарий)

плюс

6.17 -> 6.18: PCACHE provides a mechanism to use persistent memory (e.g., CXL persistent memory,
DAX-enabled devices) as a high-performance cache layer in front of
traditional block devices such as SSDs or HDDs

Тогда, может быть, это конкурент TernFS?

Хм… может быть. Но похоже, что сабж попроще.

У CD, нашего, ROM'а тоже есть (внезапно) фс.

Это получается аналог ПЗУ, но для случая, когда на отдельную микросхему места не хватило?

и кэш тут даже вредит.

Вот эту часть не понял. Если это файлы, значит память, где они лежат, медленная. Почему не оставить их в ОЗУ после первого чтения? Файлы очень большие и читаются каждый раз разные?

Там по ссылке на гитхабе они описывают проблему следующим образом:

File contents live in page cache pages, so sharing the same rootfs across N containers or kernels means N copies of the same data in physical memory.

Для заявляемого основного юзкейса вроде как очень даже имеет смысл:

The primary use case was booting Docker images: a daxfs image of a container rootfs placed in shared memory provides all kernels with a common read-only filesystem without any inter-kernel communication or network I/O.

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

В лёгкую! Установка/ или обновление по сети множества рабочих станций. загрузка по сети множества рабочих станций. Да даже часть контейнеров можно сунуть туда, для безопасности и скорости доступа. масса вариантов.

Т.е я наконец-то смогу хоть какое-то примиенение найти для 16gb vram? Практически не помню, чтобы хоть какая-то игра сожрала больше половины (а rtx конечно же не нужен)

Не знаю, мне ext4 хватает выше крыши …

Новейшая

Наглое враньё, я только что создал репозиторий для своей высокоскоростной ФС, поэтому моя более новая.

Вообще-то какой-то странноватый юзкейс.

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

Самый простой пример - подбор хеша на GPU по огромному словарю который не влезает в видеопамять.

container rootfs placed in shared memory

Тут бы вообще файлами не пользоваться. Если всё в оперативке целиком, доступ по указателю многократно быстрее, чем через open/seek/read.

В общем, костыли для докера, чтобы интерфейс был «типа файл» к области памяти.

page cache pages, so sharing the same rootfs across N containers or kernels

Вот это сейчас серьёзно так? Если N контейнеров читают один файл, он N раз копируется в памяти? Ведь если N процессов не из контейнеров, то точно нет (и так было с древних UNIX’ов ещё, когда программный код vi один раз в памяти висел для всех пользователей). Я знал, что докер ущербен, но не знал, что настолько (ведь даже chroot/jail файловый кэш не дублируют на каждый контейнер).

Поддерживаю комментатора выше.

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

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

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

И зачем тогда это дрочево если к данным можно обращаться сразу через указатель, и даже для меня макаки, считать N байт с X адреса кажется проще чем через вызовы ФС?

FPGA - это не ПЗУ. это что-то среднее между ПЗУ и ПЛМ.
а современные ещё и реально ПЗУ на борту могут иметь.

ну и вопросы не ко мне.

докеры успешно решают проблемы которых просто не существовало до их изобретения!