GFS
## Вопросы и ответы
##### Какие операции, приводящие к изменению _содержимого_ файла поддерживает GFS? Какая операция является более частой?
GFS поддерживает операции write и record append.
write - пишет в случайное место в файле.
record append - добавляет новые данные в конец файла.
Последняя операция является более частой по словам авторов:
>Third, most files are mutated by appending new data
>rather than overwriting existing data. Random writes within
>a file are practically non-existent.
***
##### GFS хорошо подходит для больших последовательных чтений. Что из себя представляет типичный клиент, который выполняет такие чтения?
В статье приводится несколько примеров:
- Большие репозитории с программами, которые его анализируют
- Приложения, генерирующие потоки данных
- Архивные данные
- Промежуточные результаты, которые сгенерированы на одной машине, а должны использоваться на другой
***
##### Не становится ли мастер узким местом при обработке всех записей и аппендов в файловой системе? С помощью каких механизмов снижается нагрузка на мастер?
При том, что мастер хранит метаданные обо всех файлах, через него не проходят данные.
Для выполнения любой операции клиент спрашивает у мастера информацию о чанке по имени файла и оффсету (скорее всего спрашивает не про один чанк, а сразу про несколько).
После этого клиент кеширует эту информацию и общается только с репликами, никак не контактируя с мастером.
***
##### Чему равен размер чанка в первоначальном дизайне GFS? А чему равен аналогичный параметр в локальных файловых системах?
Выбран был размер 64MB, при том, что в локальных файловых системах обычно используется 4KB.
##### Чем мотивирована эта разница?
Во-первых, это уменьшает взаимодействие между клиентом и мастером, так как теперь требуется спросить информацию про меньшее число чанков (в случшем случае меньше в 16К раз).
Во-вторых, это позволяет дольше сохранять TCP соединение, так как больше работы совершается над 1 чанком.
В-третих, это уменьшает количество метаданных, хранящихся в мастере, что позваляет держать их в оперативной памяти.
***
##### Зачем среди реплик одного чанка выделяется _primary_-реплика?
_Primary_-реплика единственная имеет право на модификацию файла. Она выстраивает порядок операций, изменяющих файл, а остальные реплики подчиняются этому порядку.
##### Как устроена процедура fail-over-а для _primary_-реплики чанка?
Если произошла какая-то ошибка, то _primary_-реплика отвечает клиенту о всех ошибках. Клиент в таком случае заново пытается отослать данные всем репликам и повторить операцию, после некоторого количества таких неудачных попыток клиент повторяет операцию с самого начала (с момента обращения к мастеру).
##### Как упорядочиваются записи в пределах одного чанка с учетом отказов _primary_-реплик? Что это вам напоминает?
Порядок записей задает _primary_-реплика. При этом в один момент не может быть больше одной _primary_-реплики, поэтому порядок между операциями разных _primary_-реплик задается порядком существования _primary_-реплик. Этот алгоритм напоминает алгоритм RAFT, где leader = _primary_-реплика, а время жизни одной _primary_-реплики = term
***
##### Почему записи по оффсету (даже маленькие) могут быть неатомарными?
TODO
##### Может ли такое случиться при аппенде в конец файла? Почему?
Нет, потому что TODO
***
##### Есть ли в первоначальном GFS единая точка отказа? Почему? Есть ли она сейчас?
TODO
##### Какие структуры данных образуют состояние мастера?
Мастер хранит 3 типа данных:
- namespaces для файлов и чанков
- отображение из файлов в чанки
- информация о репликах для каждого чанка
##### Какие из этих структур хранятся персистентно, на диске?
namespaces и file-to-chunk mapping хранятся персистентно на диске в виде лога операций и реплицированы на другую машину, ...
##### Какие структуры данных хранятся только в оперативной памяти? Как их восстановить в случае рестарта мастера?
... а информация о репликах хранится только в оперативной памяти. В случае рестарта мастер опрашивает все chunkserver'а о чанках, который у них есть, во время рестарта или в то время, когда chunkserver присоединяется.
***
##### Как мастеру удалить файл, если в данный момент не доступны все реплики всех блоков?
##### Может ли мастер обрабатывать создания файлов в пределах одной директории конкурентно? Как?
Да, так как для создания файла мастеру необходимо взять read-lock'и на все родительские директории, а потом write-lock на сам файл. Первое позволяет избежать удаления, переименования или снапшота родительской директории, а второе справиться с конкурентным созданием одного и того же файла.
Так как для директорий требуется только read-lock, то возможно одновременное создание файлов в одной директории.
***
##### Что ограничивает масштабируемость GFS – данные или метаданные? Почему?
Метаданные, так как все метаданные должны помещаться в оперативную память мастера.
##### От чего зависит размер метаданных GFS, из-за чего мастер может "переполниться"?
Размер метаданных пропорционален количеству чанков - на информацию о каждом чанке требуется 64 байта.
Переполнение же может произойти из-за большого количества слабо заполненных чанков - например, много файлов очень маленького размера.
##### Какое ограничение соблюдается при размещении реплик чанка?
Реплики размещают на разных стойка на случай, если вдруг целая стойка окажется недоступной.
***
##### Что мастер должен сделать на уровне метаданных при создании снапшота?
Мастер дублирует методанные необходимого файла. При этом метаданные помечаются и ссылаются на одни и те же данные до момента первой записи (copy-on-write).
Аналогичное происходит с таблицей виртуальной памяти при fork'е.
##### Зачем при создании снапшота файла мастер отзывает все лизы у _primary_-реплик чанков этого файла?
Это делается для того, чтобы при последующих модификациях файла реплики обязаны были сходить к мастеру. Мастер, зная, что файл хотят изменить, может создать копию файла, чтобы одна копия осталась в снапшоте, а вторая менялась (copy-on-write).
***
##### Зачем мастеру лог? Может ли мастер хранить его в GFS?
Мастер хранит в логе методанные о всех файлах и чанках. В случае рестарта мастер сможет узнать все методанные, применив все операции в логе от последнего чекпоинта.
Лог не получится хранить в GFS, так как в таком случае при рестарте мастер не будет знать, где, собственно, хранится лог.
***
##### Что такое _осиротевший_ чанк?
TODO
##### Что происходит, когда умирает чанк-сервер? Как мастер узнает о том, что какой-то чанк нужно дореплицировать?
TODO
##### Как можно снизить оверхед от репликации, не снижая при этом отказоустойчивость чанка? Как этому препятствует API системы?
TODO
##### Как BigTable использует GFS?
TODO
##### Как в HDFS называются мастер и чанк-сервер соответственно?
TODO