Согласно Википедии, ZFS имеет следующие ограничения:

• Макс. размер тома: 256 триллионов йобибайтов (2¹²⁸ байтов)
• Макс. размер файла: 16 эксибайтов (2⁶⁴ байтов)
• Макс. количество файлов:
  • На директорию: 2⁴⁸
  • На файловую систему: неограниченно
• Макс. длина имени файла: 255 ASCII символов (меньше для многобайтовых кодировок символов, таких как Unicode)

Почему есть эти ограничения? Что внутренне ограничивает эти параметры? Почему ZFS не мог бы иметь теоретически неограниченный размер тома, длину имени файла и так далее?

Что внутренне ограничивает эти параметры?

Длинный ответ

Ограничения ZFS основаны на целых числах фиксированного размера, потому что это самый быстрый способ выполнять арифметические операции в компьютере.

Альтернатива называется арифметикой произвольной точности, но она по своей сути медленная. Поэтому арифметика произвольной точности является дополнительной библиотекой в большинстве языков программирования, а не стандартным способом выполнения арифметики. Есть исключения, но это обычно математически ориентированные DSL, такие как bc или Wolfram Language.

Если вам нужна быстрая арифметика, используйте целые слова фиксированного размера и всё.

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

Теперь давайте обсудим практическое значение каждого из этих ограничений:

Макс. размер тома

2¹²⁸ байтов по сути уже бесконечно. Мы можем записать это число как примерно 10³⁸ байтов, что означает, что для достижения этого предела вам нужно иметь единственный ZFS пул размером с Землю, в котором каждый из своих 10⁵⁰ атомов используется для хранения данных, и каждый байт хранится элементом не больше 10¹² атомов.

10¹² атомов звучит как много, но это всего лишь около 47 пикограммов кремния.

Плотность данных в граммах составляет 2.5×10^-13 г/байт для хранения на microSD на момент написания: крупнейшая доступная SD-карта — 1 ТБ, и она весит около 0.25г.¹ MicroSD-карта не изготовлена из чистого кремния, но нельзя игнорировать упаковку, потому что нам понадобится часть этого в нашем Земном компьютере; мы предположим, что низкая плотность пластика и более высокая плотность металлических контактов в среднем составляют примерно ту же плотность, что и кремний. Нам также нужно немного лишнего здесь для учета межчиповых соединений и т.д.

Пико-что угодно — это 10^-12, так что наши 47 пг и 2.5×10^-13 г/Б приведены выше на порядок величины друг от друга. Это означает, что для первого приближения, чтобы построить один максимально большой ZFS пул из текущих крупнейших доступных microSD-карт, вам, возможно, придется использовать всю планету размером с Землю атомов, и только если вы начнете с чего-то близкого к правильной смеси кремния, углерода, золота и т.д., так чтобы у вас не оказалось так много шлака, что это подорвет оценку.

Если вам кажется, что это несправедливо, что я использую флеш-накопители вместо чего-то более плотного, такого как лента или диск, учитывайте объемы данных, а также тот факт, что мы даже не пытались учесть избыточность или замену устройства. Мы должны предположить, что этот пул ZFS размером с Землю будет состоять из vdevs, которые никогда не нужно заменять, и что они могут передавать данные достаточно быстро, чтобы вы могли заполнить пул в разумные сроки. Только твердотельные накопители имеют смысл здесь.

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

Макс. размер файла

Итак, у нас теперь есть файловая система размером с планету. Что мы можем сказать о размере файлов, хранящихся в ней?

Давайте дадим каждому человеку на планете свою равную долю этого пула:

10³⁸ ÷ 10¹⁰ ≈ 10²⁸ ÷ 10¹⁹ ≈ 10⁹

Это размер пула, делённый на население Земли², делённый на максимальный размер файла, в округленных числах.

Другими словами, каждый человек может хранить около миллиарда файлов максимального размера в своем крошечном личном сегменте нашего массива хранения ZFS размером с Землю.

(Если вас беспокоит, что наш массив хранения все еще размером с планету в этом примере, помните, что он должен был быть таким большим, чтобы достичь первого ограничения выше, так что справедливо продолжать использовать его для этого примера здесь.)

Максимальный размер файла здесь 16 EiB в ZFS, что в 16 раз больше максимального размера тома ext4, который считается сегодня неправдоподобно большим сам по себе.

Представьте себе, что кто-то использует свою долю Плана ЗФС (ранее известного как Земля) для хранения резервных копий дисковых изображений ext4 максимального размера. Более того, этот психованный клиент (всегда есть один) решил tar их, по 16 на файл, просто чтобы достичь лимита максимального размера файла ZFS. После этого у этого клиента все еще останется место сделать это снова еще около миллиарда раз.

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

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

Теперь, поскольку вы превратили поверхность Земного компьютера в ад, всем людям, пытающимся использовать этот компьютер, придется жить где-то еще, месте, где вы часто будете слышать людей, ругающих задержки со скоростью света, которые добавляют задержку к каждой транзакции между Земным компьютером и тем местом, где они живут сейчас. Если вы думаете, что ваш ~10 мс пинг в Интернете — это проблема сегодня, представьте себе, что между вашей клавиатурой и компьютером находятся 2,6 световых секунд, если мы переместим население Земли на луну, чтобы мы могли сделать этот Земной компьютер.

Ограничения ZFS по размеру томов и файлов — это действительно большая научная фантастика.

Макс. количество файлов в директории

2⁴⁸ — это примерно 10¹⁴ файлов на директорию, что станет проблемой только для приложений, которые пытаются обратиться к ZFS в качестве плоской файловой системы.

Представьте себе исследователя Интернета, который хранит файлы о каждом IP-адресе в Интернете. Допустим, что отслеживается ровно 2³² IP-адресов после того, как сначала вычли неиспользуемое пространство в старом пространстве IPv4 и затем добавили хосты, которые теперь используют адреса IPv6, чтобы сделать арифметику приятной. Какую проблему этот исследователь пытается решить, что требует от него создания системы файлов, способной хранить более 2¹⁶ — 65536! — файлов на IP?

Допустим, этот исследователь также хранит файлы по TCP-порту, так что с одним файлом на комбинацию IP:порт мы уже использовали наш множитель 2¹⁶.

Решение простое: хранить файлы по IP в поддиректории, названной в честь IP, а файлы по порту хранить в поддиректории директории, содержащей файлы по IP. Теперь наш исследователь может хранить 10¹⁴ файлов на комбинацию IP:порт, что достаточно для долгосрочной глобальной системы мониторинга Интернета.

Ограничение ZFS по размеру директории не является тем, что я бы назвал “научной фантастикой большой”, так как мы знаем о реальных применениях на сегодняшний день, которые могут достичь этого ограничения, но сила иерархии означает, что вы можете просто добавить еще один уровень директории, если столкнетесь с ограничением.

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

Макс. длина имени файла

Хотя это ограничение действительно кажется строгим, оно на самом деле имеет смысл.

Это ограничение не возникло с ZFS. Я полагаю, что оно восходит к FFS в 4.2BSD. Я не могу найти цитату, но когда это ограничение было молодым, кто-то указал, что этого пространства достаточно для “короткого письма бабушке”.

Таким образом, возникает вопрос: почему вам нужно называть свои файлы более описательно, чем это? Когда вы не можете использовать силу иерархии, чтобы умножить это ограничение на глубину директории, плюс один? Если вы можете распределить имя на 3 уровня иерархии директорий, лимит на имя полного пути становится 4 × 255 = 1020 символов.

Хотя внесенное изменение в OpenZFS, примененное в октябре 2024 года, умножает лимит байтов примерно на 4, имейте в виду, что в условиях наихудшего случая расширения UTF-8, лимит кодовой точки остается прежним. Для наших целей здесь не так много смысла спорить о разнице между 255 байтами расширенного ASCII и 255 максимально широкими символами UTF-8; темы Универсального кода хорошо освещены в других источниках. Если вы можете добавить больше текста в имя под этим патчем, ограничив свой набор символов, отлично, но с моей точки зрения, это изменение скорее признание того, что UTF-8 теперь существует, чем предоставление людям возможности еще больше описывать содержимое файла в имени.

В конечном итоге, имена файлов — это удобство поиска для пользователей, а не для компьютера, и люди редко имеют хорошо обоснованные причины использовать более 255 символов для полезного описания содержания файла. Более высокий лимит просто не был бы полезен, кроме как в нишевых случаях. Первоначальное ограничение старое (1983) потому что с тех пор люди не приобрели способность справляться с более длинными именами файлов.

Если вы спрашиваете, откуда берутся эти странно выглядящие значения, это 2⁸ и 2¹⁰ минус один для нулевого завершителя, чтобы обозначить конец строки имени файла.

Короткий ответ

Практически говоря, какие ограничения?

Сноски:

1. Я измерял это, используя весы с точностью 0.01 г.

2. 7.55 миллиарда, на момент написания. Выше мы округляем это до 10¹⁰, что мы должны достичь к середине века.