Позволяет ли файловая система Google отображать содержимое каталогов?

В документе GFS в разделе 4.1 описывается, как GFS может выполнять одновременные изменения в каталоге, требуя только блокировки чтения каталога для каждого клиента — в GFS нет фактического индексного дескриптора, поэтому клиенты могут создавать, удалять или изменять. /x/y/somefile, в то время как блокировка чтения требуется только для /x/ и /x/y/.

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

Предположим, что какой-то клиент GFS хочет просмотреть имена всех файлов в каталоге, например, ls. Как это возможно без итерации по всем узлам метаданных?

Клиент может поддерживать свою собственную версию того, как, по его мнению, выглядит дерево каталогов в GFS, но это будет работать только в том случае, если каждый клиент будет придерживаться своего собственного каталога.


person VF1    schedule 30.05.2014    source источник


Ответы (1)


Основная таблица поиска предлагает доступ к единому концептуальному дереву из узлов. Для этого он перечисляет все пути имен к узлам. Некоторые узлы являются каталогами. Единственные данные принадлежат конечным узлам, не относящимся к каталогу. Например, эти пути:

/a/b/foo
/a/b/c/bar
/a/baz/

опишите это дерево:

\
 a/--b/--foo
 |  \
 |   c/--bar
 baz/

Каждый путь идентифицирует узел. Узлы, являющиеся потомками узла, — это те, чьи пути в таблице поиска на одно имя длиннее. Чтобы перечислить дочерние узлы узла, нужно перечислить все пути в таблице поиска, которые на одно имя длиннее, чем его путь. Под метаданными в документе подразумевается информация о том, заблокирован ли узел и каким образом, а также о том, где находятся его (неразделяемые) данные для конечного узла, не являющегося каталогом.

Нельзя перемещаться, посещая узлы каталогов, которые владеют данными, которые дают имена дочерних и родительских узлов и являются ли они каталогами, как в Unix/Linux. Копирование листа означает копирование его данных в другой лист, например Unix/Linux cat, а не cp. Я предполагаю, что можно скопировать поддерево, которое добавит новые пути в таблицу поиска и скопирует данные для листьев, не относящихся к каталогу.

Нельзя использовать такие технические термины, как «файл» или «каталог», как будто они означают одно и то же в обеих системах. Что можно сделать, так это рассмотреть, как GFS и Unix/Linux управляют одним и тем же деревом путей имен через узлы каталога к листьям каталога и листьям, не владеющим данными каталога. Но после этого другие части состояния файловой системы (метаданные и данные) и их операторы различаются. В уме поместите «GFS-» и «Unix/Linux-» перед каждым техническим термином, кроме тех, которые относятся к деревьям именованных узлов.

РЕДАКТИРОВАТЬ: Примеры.

1.

Предположим, что какой-то клиент GFS хочет просмотреть имена всех файлов в каталоге, например, ls. Как это возможно без итерации по всем узлам метаданных?

Список каталогов вернет пути в таблице поиска, которые расширяют путь к данному каталогу. GFS будет предлагать команды файлового сервера для выполнения таких действий или поддержки таких действий, скрывая свою реализацию. Было бы достаточно (но медленно), чтобы иметь возможность перебирать таблицу поиска. Например, лс /а/б:

/a/b/foo
/a/b/c/bar

2. Чтобы скопировать дочерние узлы исходного узла в дочерние узлы целевого: Для каждого пути, который расширяет исходный путь, добавьте в таблицу поиска путь, полученный путем замены этого префикса целевым путем. Предположительно команда копирования, создающая новые узлы, копирует связанные данные для не-каталогов. Например, копирование дочерних элементов /a/ в /a/b/c/ добавляет:

/a/b/c/b/foo
/a/b/c/b/c/bar
/a/b/c/baz/

давая:

\
 a/--b/--foo
 |   \
 |    c/--bar
 |    |--b/--foo
 |    |  \
 |    |   c/--bar
 |    baz/
 baz/
person philipxy    schedule 31.05.2014
comment
Я никогда не отрицал, что файл/каталог GFS отличается от файла/каталога Linux/Unix. Я принимаю это. У меня вопрос: учитывая, что GFS отличается, как выполняет директивы, требующие древовидной структуры? Чтобы сказать, скопируйте поддерево, как вы упомянули, полностью ли мастер проходит всю листовую таблицу для всех путей, которые соответствуют соответствующему префиксу? - person VF1; 31.05.2014
comment
Я не говорил, что вы отрицаете различие. (?) Вы сказали, что не видели, как он поддерживает явную древовидную структуру: в таблице поиска. Это не листовая таблица; у него есть путь для каждого узла. Это своего рода конец ответа. Команды файловой системы GFS будут (каким-то образом) читать и изменять таблицу поиска и связанное с ней состояние файловой системы. Я ничего не видел о реализации таблицы поиска (кроме сжатия префикса): это абстракция. Метаданные связаны с путем; будет команда, чтобы получить его. Но обход — это концепция реализации. Это помогает? - person philipxy; 31.05.2014
comment
Да, это проясняет некоторые вещи (пожалуйста, включите в ответ то, что вы сказали). Я понимаю, что команды (каким-то образом) будут читать и изменять таблицу поиска, но мне кажется, что с процедурой блокировки, упомянутой в статье, эта (каким-то образом) деталь реализации должна быть полным обходом таблицы (что было бы вопиющим образом медленным) - если бы GFS поддерживала фактическое дерево только для того, чтобы отслеживать, где находятся узлы, ему потребовались бы блокировки записи в управляемых каталогах, которые в документе утверждалось, что он не использует. - person VF1; 31.05.2014
comment
Например, в вашем последнем примере копирования дочерних элементов /a/b/c/ в /a/ (обратите внимание, я изменил порядок, чтобы избежать самокопирования), как GFS получит имена /a/b/c/* из своих собственных метаданных для создания моментального снимка? Кажется, что он должен пересекать b/c дизайна. - person VF1; 31.05.2014
comment
В самокопировании нет ничего плохого — источник имеет значение формы, и такая же фигура добавляется к цели. - person philipxy; 31.05.2014
comment
Хорошо, что касается самостоятельного копирования, но это не относится к делу - я пытаюсь сказать, что нет (сразу видимого) простого способа сканирования каталога, что странно, поскольку в документе эта возможность упоминается позже. - person VF1; 31.05.2014
comment
Любое описание находится на определенном уровне абстракции. Вы предполагаете имплантации. Какой обход? Какой стол? Какое дерево? Он действует так, как будто у него есть дерево, то есть он действует так, как будто у него есть список путей. Извините, я не знаю, что сказать. Получить больше опыта работы со структурами данных? (Много журналов 2 посвящено деревьям.) - person philipxy; 31.05.2014