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 плюсов просто нет.