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 мм? Ещё видел что можно создавать в нем же пулл с другой файловой системой это миф или как мм?

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

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

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

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