OpenZFS 2.3.0

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

Из ядра:

/*
 * Structure of a directory entry
 */
#define EXT4_NAME_LEN 255
/*
 * Base length of the ext4 directory entry excluding the name length
 */
#define EXT4_BASE_DIR_LEN (sizeof(struct ext4_dir_entry_2) - EXT4_NAME_LEN)

struct ext4_dir_entry {
	__le32	inode;			/* Inode number */
	__le16	rec_len;		/* Directory entry length */
	__le16	name_len;		/* Name length */
	char	name[EXT4_NAME_LEN];	/* File name */
};

Поздравляю, а на минте уже поезд ушёл. 🤡

Это не совсем так. В люнегзе для пользовательского API стоит лимит 255 символов.

https://github.com/torvalds/linux/blob/master/include/uapi/linux/limits.h#L12

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

Ну, то есть, сверху имена длиннее 255 байт не пхать. Ну разумно, чо! Когда-то 16 байт что-ли было :)

Но судя по быстрому грепу, это число дофига где используется..

Мне пока только проверки на PATH_MAX попадались.

Да, я проверил по https://elixir.bootlin.com/linux/v6.12.6/A/ident/NAME_MAX

Это ограничение больше используется в драйверах файловых систем и на стыке VFS и драйвера. Оно ниже моих текущих ядерных потребностей. И то, далеко не везде. В NTFS-е том же имена длиннее. Походу, это какое-то наследие старых времен. Может где в libc и есть, и то не факт, NTFS бы не работал.

И да, ты ж сам написал:

Максимальная длина имён файлов и каталогов увеличена с 255 до 1023 байт;

Ну и где та константа NAME_MAX?

И да, ты ж сам написал:

Максимальная длина имён файлов и каталогов увеличена с 255 до 1023 байт;

Я нигде не писал, что это гарантировано работает повсюду. Это вообще строчка из их релиза, не понимаю причём тут я.

Плюс, учти, что ZFS поддерживает не только Linux. В FreeBSD всё может быть чуть иначе, мне лень смотреть.

Поддержка прямого обращения к диску в обход ARC

WAT? … а, O_DIRECT таки завезли, а раньше не было?.. интересно…

это потому что линукс - не TruЪ UNIX(TM)!

UNIX System V has a filename size limit of 14 characters. Ken Thompson thought is was an acceptable limit.

так что ZFS лишь продолжала традицию. И так по царски до 256 расиширила! ))))))

а Боромир увеличил бы сразу до 2046!

Когда-то 16 байт что-ли было

14!

Ну так есть какое-то старое ограничение на длину имени. Эта константа не универсальная, кое-где осталась, но, судя по коду ядра, — именно, что «кое-где». А для dentry для каждой файловой системы действует свой лимит. В основном — 255 байт, но есть нюансы в обе стороны.

https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits

Заезжай в гости, Venix (который System III) на Pro380 поставим, проверим! Если пятидерьмовые дискеты с дистрибутом еще не сдохли :)

Прекрасно. Ждём в Proxmox. Надо тесты погонять - если с direct io нет просадки, то буду optane с lvm на zfs переводить.

Ну, вон в одном известном ТруЪ-Unix с бумажкой до сих пор:

#define _POSIX_NAME_MAX 14

Только что проверил. А в ихнем яблочном HFSe таки 255, кстати.

Помнится, имел я отношение к разработке некого российского аналога с идеологией OpenNAS, но размером с массив от «Ядра», там как раз использовались оптаны как раз с ZFS-томами. Мы сравнивали перформанс нашего поделия с чем-то китайским поэнтерпрайзнее Свинолоджи, но поменьше Хуавея, уж не помню как оно называлось, ну так наше поделие просасывало по перформансу, что называется «не нагибаясь» :(. Дело было довольно давно, то ли ZFS тогда такой был, то ли мы его готовить не умели, но что-то все грустные ходили. Вот на чем то же Ядро свои массивы строит я чот спросить не догадался, хоть и мог бы. Я тут недавно встретил своего бывшего коллегу случайно, он датацентрами какими-то рулит, так поделия от «Ядра» он хвалил очень.

Да, интересно, что там под капотом.

И интересны бенчмарки zfs на optane.

Вот этого я уже не помню, еще сильно до ковида дело было. Да и это была рабочая информация, была бы под рукой, все равно бы я поделиться не смог.

И интересны бенчмарки zfs

… вечное out-of-tree

на optane.

… RIP

WAT? … а, O_DIRECT таки завезли, а раньше не было?.. интересно…

O_DIRECT – это фикция. В половине случаев оно не работает, на самом деле.

Хуже того, в случае того же L2ARC, непонятно что вообще это O_DIRECT должно делать: писать мимо кэша страниц в памяти в кэш на промежуточном диске? Или писать сразу на целевой диск мимо промежуточного? Или и туда и туда? Как насчёт сетевых ФС?

В общем, нюансов просто вагон.

Если бы все было так просто, так SPDK бы не придумали. Народ в основном в обход ядра через этот самый SPDK перформанса добивается. Та же история, что и с DPDK, только про диски.

Это конечно все круто но как этот zfs в плане шифрования и загрузки с dracut норм? Он быстрее например связки luks2 btrfs на nvme мм? Ещё видел что можно создавать в нем же пулл с другой файловой системой это миф или как мм?

Стоит ли смотреть в сторону этой ФС домашнему десктопному линуксоиду

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

Проще нормальный рейд купить

АПХАХАХАХАХАХАХАХАХАХАХАХАХ адепты хардварных рейдов в чате! Все в машину!

Я правильно помню, что пользоваться этим невозможно, потому что его не принимают в ядро из-за лицензий?

Я правильно помню, что пользоваться этим невозможно, потому что его не принимают в ядро из-за лицензий?

Нет, неправильно.

но что интересно, у оракла (Sun HW) было поделие где из сервера делали схд и как раз на схд. возможно даже, что ещё до сих пор доступно. на самом деле схд имеет смысл, там все ваши проблемы типа разруливаются менеджерами среднего звена из вендора (читай, перекладываются на индусов из Бангалора).

Ну если тебе снапшоты нужны и месье понимает толк в извращениях, то в добрый путь, как грится…. :)

Инкрементальные бэкапы – это очень и очень круто и удобно

Снапшоты и инкрементальные бакапы - немного разные вещи.

С СХД всё норм, я над «купить нормальный рейд» ржу.

Или для него и ext4 выше крыши?

Плюсы:

• встроенная проверка целостности данных, может спасти от хранения битых файлов в бэкапе.

• снапшоты можно использовать для дополнительной подстраховки или как средство инкрементального бэкапа.

• сжатие полезно, но не для фоточек с роликами.

Минусы:

• усложнение конфигурации. Ничего необычного, но любая сложность увеличивает риск человеческой ошибки.

• не получиться использовать свежие ядра на железке.

• любит кушать память. Может потребоваться дополнительная настройка в некоторых случаях.

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

Если не использовать фишки zfs, то и плюсов от неё особо для файлопомойки не будет. С другой стороны, у ext4 плюсов просто нет.

версия замечательного проекта OpenZFS

Когда я написал, что Btrfs замечательная файловая система у буйных случилась истерика… Это лишь доказывает, что пользователи Btrfs более вменяемые — ничего более.

максимальная длина имён файлов и каталогов увеличена с 255 до 1023 байт

А 1 байт для чего зарезервирован? 2^8 = 256-1…

Пока никаких «киллер-фич»

С другой стороны, у ext4 плюсов просто нет.

Есть один - файлы легко восстанавливать, которые даже специализированные утилиты не видят, просто читая посекторно соержимое раздела, пока нужное не найдешь

непонятно что вообще это O_DIRECT должно делать

Из man 2 open вполне понятно что он должен делать: по возможности байпассить любые кеши, для минимизации их влияния при записи на железку. Это важно для софта, который имеет свои техники кеширования. К примеру, БД.

Как насчёт сетевых ФС?

Тут все просто: где это возможно – байпассим, где не возможно – пишется в кеш и при этом честно заявляя в описании особенностей работы каждой ФС.

Ну вот, например. Чота не сказать, что ZFS это прям чемпион по производительности

https://www.phoronix.com/review/optane-linux-raid?__cf_chl_tk=1D1rW_7grMI8nZE...

Чота не сказать, что ZFS это прям чемпион по производительности

ZFS тюнится под конкретный ворклод. И часто в определенных условиях обходит по производительности другие ФС.

Это я знаю, и вопрос тюнинга ZFS меня одно время интересовал по работе. Но найти чего-то внятного на тему как тюнить правильно то ли нам найти не удалось, то ли эту проблему решали без меня (я другим стал тогда заниматься), но лично для меня вопрос «как тюнить ZFS» остался пока без ответа. Тогдашние наши эксперименты показали не особо чемпионскую производительность. См мой коммент про воспоминания выше. Сейчас меня спрашивать о том, как что тогда делали бесполезно. Не помню. Помню только результат.

Из man 2 open вполне понятно что он должен делать: по возможности байпассить любые кеши, для минимизации их влияния при записи на железку.

Ну вот теперь ZFS умеет мимо ARC писать. Вопрос, что делать с L2ARC, остаётся открытым.

Это важно для софта, который имеет свои техники кеширования. К примеру, БД.

Есть и другое мнение:

On Fri, 10 May 2002, Gerrit Huizenga wrote:
> In message <Pine.LNX.4.44.0205100854370.2230-100000@home.transmeta.com>, > : Li
> nus Torvalds writes:
> >
> > For O_DIRECT to be a win, you need to make it asynchronous.
>
> O_DIRECT is especially useful for applications which maintain their
> own cache, e.g. a database.  And adding Async to it is an even bigger
> bonus (another Oracleism we did in PTX).

The thing that has always disturbed me about O_DIRECT is that the whole
interface is just stupid, and was probably designed by a deranged monkey
on some serious mind-controlling substances [*].

It's simply not very pretty, and it doesn't perform very well either
because of the bad interfaces (where synchronicity of read/write is part
of it, but the inherent page-table-walking is another issue).

I bet you could get _better_ performance more cleanly by splitting up the
actual IO generation and the "user-space mapping" thing sanely. For
example, if you want to do an O_DIRECT read into a buffer, there is no
reason why it shouldn't be done in two phases:

 (1) readahead: allocate pages, and start the IO asynchronously
 (2) mmap the file with a MAP_UNCACHED flag, which causes read-faults to
     "steal" the page from the page cache and make it private to the
     mapping on page faults.

If you split it up like that, you can do much more interesting things than
O_DIRECT can do (ie the above is inherently asynchronous - we'll wait only
for IO to complete when the page is actually faulted in).

For O_DIRECT writes, you split it the other way around:

 (1) mwrite() takes the pages in the memory area, and moves them into the
     page cache, removing the page from the page table (and only copies
     if existing pages already exist)
 (2) fdatasync_area(fd, offset, len)

Again, the above is likely to be a lot more efficient _and_ can do things
that O_DIRECT only dreams on.

With my suggested _sane_ interface, I can do a noncached file copy that
should be "perfect" even in the face of memory pressure by simply doing

	addr = mmap( ..  MAP_UNCACHED ..  src .. )
	mwrite(dst, addr, len);

which does true zero-copy (and, since mwrite removes it from the page
table anyway, you can actually avoid even the TLB overhead trivially: if
mwrite notices that the page isn't mapped, it will just take it directly
from the page cache).

Sadly, database people don't seem to have any understanding of good taste,
and various OS people end up usually just saying "Yes, Mr Oracle, I'll
open up any orifice I have for your pleasure".

			Linus

[*] In other words, it's an Oracleism.

Тыц: https://yarchive.net/comp/linux/o_direct.html

Одна из основных проблем в скорости IO в лялексоюниксах в том, что оно синхронное. Интерфейс POSIX AIO настолько убог и упорот, что я ни разу не видел ни одной проги, которая бы его использовала. Вместо него изобрели вагон ивент-лупов (из семи залупов) и аж целый io_uring. Я так прозреваю, что Лойнус прав, и лучшей (т.е. более хорошей) производительности можно достичь без O_DIRECT.

Главное не то на какой ОС держать данные, а в том, в скольки копиях хранить важные данные. ZFS не панацея и многое зависит от сопутствующих знаний в работе с ней. А выбор между ней и другой фс зависит от нужности или не нужности конкретных её фичей, которых у зфс не мало.

ТС вроде и не говорил, что одинаковые. Спапшоты zfs поддерживают инкрементальные бекапы, всё остальное отсюда следует.

Вопрос, что делать с L2ARC, остаётся открытым.

Если был вызов с флагом O_DIRECT то скипать кеширование в ARC и страницы в L2ARC помечать как не валидные. Или я чего-то не понимаю?

Есть и другое мнение:

Лялекс, конечно, прав в этом вопросе. Но речь идет о ZFS, в котором «своя атмосфера» по работе с кешем. И без поддержки O_DIRECT не было возможности сказать ФС, мол, ни черта не кешируй, так как, исходя из логики работы программы, твой кеш нафиг никому не нужен. И чтоб добиться хоть какой-то производительности приходилось логику кеширования полностью выносить на сторону ФС, с которой она справляется с переменным успехом.

Интерфейс POSIX AIO настолько убог и упорот, что я ни разу не видел ни одной проги, которая бы его использовала.

qbittorrent юзает либу libtorrent-rasterbar, которая для работы с файлами юзает AIO вызовы через boost-libs. На самом деле, много кто юзает под капотом. Начальная реализация да, была убогой. Но последние пару лет, по крайней мере во Фряхе, немного причесали.

изобрели вагон ивент-лупов (из семи залупов)

Эти семь залупов, как я понимаю, по большей мере, были созданы для того, чтоб система могла хоть что-то делать параллельно пока ждет данные от синхронного вызова. Естественно они не избавляют от фундаментальных проблем реализации I/O подсистем.

Если был вызов с флагом O_DIRECT то скипать кеширование в ARC и страницы в L2ARC помечать как не валидные. Или я чего-то не понимаю?

Достаточно дерьмовая идея, хотя бы потому что это убьёт производительность, а не поднимет её. Типичный сценарий использования L2ARC: NVMe-кэш перед рейдом вертушек.

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

А что такое ARC, по-твоему? Это как раз логика кеширования на стороне ФС.

qbittorrent юзает либу libtorrent-rasterbar, которая для работы с файлами юзает AIO вызовы через boost-libs.

Boost.Asio использует epoll и io_uring в лялексе, а не POSIX AIO.

https://www.boost.org/doc/libs/1_83_0/doc/html/boost_asio/overview/implementation.html

If BOOST_ASIO_HAS_IO_URING is defined, uses io_uring for file-related asynchonous operations.

Uses epoll for demultiplexing other event sources.

Optionally uses io_uring for all asynchronous operations if, in addition to BOOST_ASIO_HAS_IO_URING, BOOST_ASIO_DISABLE_EPOLL is defined to disable epoll.

Эти семь залупов, как я понимаю, по большей мере, были созданы для того, чтоб система могла хоть что-то делать параллельно пока ждет данные от синхронного вызова. Естественно они не избавляют от фундаментальных проблем реализации I/O подсистем.

Не система, а программа. Я сейчас про убогость юниксового API в юзерспейсе, все эти open/read/write/select.

Но как бы да, так и есть.

… Спапшоты zfs поддерживают инкрементальные бекапы, всё остальное отсюда следует.

Т.е. если навернулся носитель, я смогу восстановить ФС из снапшотов на другом носителе?

… Спапшоты zfs поддерживают инкрементальные бекапы, всё остальное отсюда следует.

Т.е. если навернулся носитель, я смогу восстановить ФС из снапшотов на другом носителе?

Если ты их туда послал через zfs send.

Да, см. коммент выше (:

Я имел в виду бенчмарки на 2.3

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

Вероятно, ZFS за деньги предоставляет какие-то тулзы и метрики на этот счет

Нету у ZFS платной версии.

А то, что Оракл продает, это что? Или у них только Oracle ZFS Storage в виде железки?

У минта, потому и нишмагли.

Если бы только у Mint. У них ведь вся основная база это Ubuntu LTS и свои всякие штуки чисто графические в основном.

А то, что Оракл продает, это что? Или у них только Oracle ZFS Storage в виде железки?

Это железка.^W^W Я свечку не держал, но прозреваю, что у них там солярка со своим ZFS. К OpenZFS это отношения не имеет. OpenZFS основан на последних открытых исходниках солярки из 2010 года, с тех пор у них полностью своя разработка без участия Oracle.

Виртуалку можно скачать отсюда: https://cloudmarketplace.oracle.com/marketplace/en_US/listing/97279348

Из описания звучит как какой-то долгострой. Не знаю сколько лет эту файловую систему пилили в Sun, но если затем, за 20 лет после продажи Sun и открытия всего кода эта файловая система так и не стала меинстримом, то уже никогда она им не станет. Выпиливание ZFS из установщика Mint лишь подтверждает эту теорию.

ZFS это не только volume-менеджер, но и крутая файловая система.

У той же ext4 банально нет контрольных сумм для данных. При их физическом повреждении на диске (т.н. bitrot), бэкап может пройти штатно (диск может просто не заметить возникшей ошибки), а когда хватишься (например, через несколько лет) - бэкапы с ещё целой версей файла уже может оказаться перезаписанными. Усё, не видать своих биткоинов, или любой другой ценной инфы.

ZFS и BTRFS же сгенерируют ошибку чтения во время создания бэкапа или во время scrub, вовремя привлекя тем самым внимание пользователя (не забываем настроить уведломления на почту в ZED при возникновении проблем с пулом). В идеале, надо бы ещё память с ECC, чтобы избежать повреждение данных/метаданных в оперативке.

Для, ZFS, как и любая другая Copy-on-Write ФС будет медленнее ext4, но современные NVMe-диски минимизируют влияние просадки произодительности на реальный опыт испльзования. В некоторых задачах, грамотно затюненная ZFS может оказаться даже быстрее, за счёт хитрого многоуровневого кеширования и использования фич вроде отдельных накопителей для L2ARC/метаданных/лога, превращая кучу медленных HDD в массив с более-менее сносным IOPS. Зато CoW даёт приколюхи вроде снэпшотов, которые оценит даже вполне себе домашний юзер, получающий возможность сделать моментальный «бэкап» перед обновлением системы, например.