Какая файловая система в Linux поддерживает более 4 млрд файлов?

Question

[Сергей Пуговкин]

Какая файловая система в Linux поддерживает более 4 млрд файлов?
Как поступают крупные "хостинги фоток", вроде Facebook?

Comments

[dmfun]

Файлы можно и в базе и в архиве хранить (а там можно их безграничное число).

[Валентин]

Посмотри https://www.youtube.com/watch?v=wk6CoqEmX6Q&list=P... - рассказывают, как хранят много статики.

Answer 1

[pfg21]

все зависит от от "длины в байтах" UID файла.
используют файловые системы с динамическим выделением inode (xfs zfs btrfs и т.д. ) или используют распределенные файловые системы.
первые удобны для односерверной конфигурации.
вторые удобны для многосерверных систем (ну это и ежу понятно)
Кста вторые не всегда выглядят как полноценная файловая система. как вариант, самописная система управления файлами в виде бд, которая по уникальному идентификатору файла выдает URL, по которому его можно найти. а уж на серверах локальное количество файлов влезает в какие-либо рамки.

Answer 2

[Дмитрий Александров]

Какая файловая система в Linux поддерживает более 4 млрд файлов?

К примеру zfs имеет космические возможности.

Как поступают крупные "хостинги фоток", вроде Facebook?

Ставят кучу серверов и распределяют между ними как то так(очень простой пример и чаще всего все намного сложнее):
1) имеется куча серверов с именами типа n1.example.com ,n2.example.com, n3.example.com
2) на балансировщике example.com решается на какой сервер загружать картинку.
3) кроме того имеется дедублицирующий алгоритм\фс . Т.е. к примеру перед загрузкой картинки считается ее sha хэш и если такой уже есть то просто возвращается ссылка иначе загружается и возвращается ссылка.

Answer 3

[cssman]

крупные хостинги имеют кучу сервер нод

Answer 4

[protven]

Посмотрите в сторону XFS. Но есть мнение что одним лишь выбором "правильной" файловой системой вы не обойдетесь.

Answer 5

[awdemme]

Ну например, ВКонтакте под хранение фото вообще не используются огранизация файлов в каталогах файловых систем.

Система там такая:

Очередное добавленное фото пишется на диск. Грубо говоря в один файл.
Отдельно сохранются в БД метаданные.
Следующее фото дописывается после предыдущего.
Фото никогда не удалаются, просто корректируются метаданные.

P.S.:
Сбор мелких файликов в один большой и работа с ним одним как с набором мелких файликов используются в ИТ уже много десятков лет.

UPD:
Так ведь проблема не только в количестве файлов.

Есть еще проблема фрагментации, когда куча места будет пропадать просто так.
Дело в том, что файловые системы хранят информацию блоками.
Например, блок 4 килобайта. Это или один файл или часть одного файла. Но не 2 разных файла.
Пишем 10 файлов по 1 килобайту. Занято 10 блоков. В них 10 килобайт полезных данных. Но все 10 блоков считаются занятыми и более не могут использоваться ни под что иное. То есть 40 килобайтов. 10 полезных. И 30 просто так.

Comments

[dmfun]

Это если преимущественно файлы маленькие будет проблема с потерей из-за блоков. Фрагментация скорее на скорость доступа влияет и скорость чтения. Один фильм скопировать быстрее, чем несколько тысяч файлов объёмом в 10 раз меньше.

[awdemme]

dmfun: На 4 миллиардах файлов, поверь, потерь будет более чем много.
Независимо от размеров файлов.

[dmfun]

awdemme: ничего кроме математики. Процент потерь считается очень просто, как и объём, но тут скорее важен процент. Если средний размер файла 100 кб, то потеря 2% при 4кб. Вообще нужно всю систему целиком считать, нельзя отталкиваться от одного параметра.

[awdemme]

dmfun:
Зависит не от размера файлов.
А от того какой остаток от деления их размера на размер блока ФС у большинства файлов.
А 4 млд. файлов по 100 килобайт - это вообще мимо, там будет пол-пентабайта - это вообще не один компьютер.

[АртемЪ]

@awdemme

Очередное добавленное фото пишется на диск. Грубо говоря в один файл.
Отдельно сохранются в БД метаданные.
Следующее фото дописывается после предыдущего.
Фото никогда не удалаются, просто корректируются метаданные..

Именно так работает большинство известных файловых систем.

Пишем 10 файлов по 1 килобайту. Занято 10 блоков.

Далеко не факт.

[АртемЪ]

awdemme: Ну если вы не согласны с этим объясните пожалуйста как оно на самом деле.
И общаться надо культурнее.

[awdemme]

АртемЪ:

Именно так работает большинство известных файловых систем.

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

[awdemme]

АртемЪ:

Далеко не факт.

Вопрос только в размере блока.
512 он байт, 4 килобайта или 64 килобайта.
В остальном все однотипно - под файл выделяется определенно количество блоков на диске.
Один и тот же блок не может быть использован разными файлами одновременно.
Из-за этого происходит потеря места. Ведь нет никаких гарантий, что размеры файлов строго кратны размерам блоков.

Некоторые файловые системы умудряются писать в блоки несколько файлов, занимая все свободное место. Но большинство файловых систем все же так не поступают.

[АртемЪ]

awdemme: Во многих файловых системах, в частности в NTFS небольшие файлы, размер которых значительно меньше размера кластера пишутся в файл самой файловой БД, Хотя это служит не столько для экономии места, сколько для более быстрого доступа к файлам.

Файлы побольше пишутся отдельно, и остаются "хвосты"
В итоге если на ФС с размером кластера 4кб записать 1000файлов размером 50байт - общий размер занятого ими места будет около 52кб, т.е 13кластеров
А если на ту же ФС записать 1000файлов размером 3кб - общий размер занятого места на диске будет около 4мб, т.е 1000 кластеров.

[awdemme]

АртемЪ:
занятые частично кластера все равно остаются.

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

Только специфические append only системы такие как описанная выше система хранения фоток в Контакте - полностью избавлены от этой проблемы.

[АртемЪ]

awdemme: Конечно остаются.
И избавиться от этого полностью не получится даже в специфических ФС, хотя их можно минимизировать.
У самой ФС размер кластера может быть какой угодно, но вот сектор- минимальный блок информации который сам диск может записать обычно равен 4килобайтам в современных дисках. Т.е если ФС поручила диску записать информацию или прочитать ее, то минимальная порция будет 4килобайта.

[awdemme]

АртемЪ:
Мне кажется, что вы не понимаете суть:

В специфических системах append only - как раз 0 проблем избавиться от незаполненных мест.
там просто нет понятия отдельных файлов с картинками/видео - если мы о ВКонтактовской системе хранения медиа-данных.
Запись идет последовательно-непрерывно.
Грубо говоря - мы получаем один гигантский файл.
Внутри него дырок нет.

[АртемЪ]

awdemme: Незаполненные места будут даже в случае одного файла.
На диск запись идет так же кусками по 4кб, потому что это минимальный объем информации которым диск может оперировать.
А один конкретный запрос на чтение или на запись в файл не всегда кратен 4кб.
Например к одному гигантскому файлу надо дописать информацию из 3 небольших файлов по 80байт - в сумме 240байт, но дописать можно только 4кб.

Поэтому они будут всегда, вопрос лишь в том насколько много.

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

[awdemme]

АртемЪ:
Все таки не понимаете преимуществ append only.

Если там один огромный файл - то проблема недозаполненности блока - только в самом последнем блоке. Всегда.

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

Он является недозаполненнм просто потому что больше нет никаких данных, которые можно было бы сохранить.

Как только туда будут дописаны очередные 10 картинок - это недозаполненный блок будет заполнен. А недозаполненным станет уже новый последний блок в файле.

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

[АртемЪ]

awdemme: Так можно сделать, если периодически запускать задание сжатия этого файла, или перед записью читать последний недописанный блок

[awdemme]

АртемЪ:
еще раз - append only означает, что данные пишутся и никогда не меняются.
в том числе - никакого сжатия.

перед записью читать недописанный блок не нужно.
если не было перезагрузки компьютера.

[АртемЪ]

awdemme: Ну и пойди нахрен, если нормально общаться не умеешь.

[sim3x]

awdemme: оскорблять никого не нужно

Answer 6

[Vladimir Zhurkin]

Какая файловая система в Linux поддерживает более 4 млрд файлов?
Как поступают крупные "хостинги фоток", вроде Facebook?

Крупные игроки обычно используют распределенные ФС. Например Facebook использует hdfs из Hadoop.
В yandex используют блобы (и не только они) - яркий пример - reverbrain.com/eblob
Можно смотреть в сторону ceph и других.