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

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

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

Что внутренне ограничивает эти вещи?

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

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

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

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

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

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

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

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 , который сегодня считается смехотворно большим сам по себе.

Представьте, что кто-то использует свой кусок Planet ZFS (ранее известный как Земля) для хранения резервных копий образов дисков 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 символов.

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

Если вы спрашиваете, откуда берется странное значение «255», это некоторое ограничение, основанное на размере 8-битного байта. 2 ⁸ составляет 256, а значение N-1 используется здесь , вероятно , означает , что они используют нулевой терминатор , чтобы отметить конец имени файла строки в поле в 256 байт в метаданных каждого файла.

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

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

Примечания:

1. Я измерил это, используя шкалу, указанную с точностью до 0,01 г.

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