Вопрос по распределённым файловым системам.

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

Да.

Параллельной будет РФС, которая может распределять части одного файла по нескольким узлам, а симметричные используются преимущественно в высокопроизводительных кластерах?

https://ru.wikipedia.org/wiki/Классификация_животных_(Борхес)
Одно не мешает другому.

будут ли другому клиенту мгновенно видны изменения, вносимые в текстовый файл другим клиентом, если вносящий изменения ещё не закрыл файл

Пока не закрыл - они вполне возможно, и на локальной фс видны не будут.

могут ли одновременно два клиента редактировать один и тот же текстовый файл, и видеть изменения, вносимые друг другом?

Могут. Опять-таки, как и на локальной системе.

Есть ли принципиальная разница между сетевыми ФС и распределенными ФС?

Ты лучше конкретный вопрос задай.

1) всякие бывают

3) это даже локально не заработает, если после каждого байта не сохраняться

даже при этом гарантий нет. http://danluu.com/file-consistency/

TC, у тебя в голове каша. distributed file systems бывают очень разные, что конкретно ты хочешь узнать, и о какой конкретно системе? если просто желаешь разобраться, почитай что-нибуть по системному программированию под юникс и любой учебник по распределенным системам. тебе нужно понять что есть файлы, что происходит при работе с ними для начала, а затем уже разобраться как работают несколько популярных распределенных фс, для чего лучше всего читать их собственную документацию. а как оно в википедии называется — это ты потом поймешь, когда ты ее откроешь и увидишь что «ага, это как гластер а вот это как hdfs».

даже при этом гарантий нет. http://danluu.com/file-consistency/

КСЖ ААА. Теперь я вообще не понимаю, как умудряются кривописанные программы для моделирования на жутко древних проприетарных распределенных ФС.

То есть, я могу форматировать жесткий диск в распределённую файловую систему так же, как и в любую другую локальную файловую систему?

Просто хочу разобраться в них, для начала. Читал различные статьи и на русском и на английском, и как то ни одна не дала мне полноценного общего представления о РФС. Не порекомендуешь какое нибудь пособие по данной теме?

Ну да. В люстре, например, это выглядит как mkfs -t lustre и вперде...

А вот ещё такой вопрос. в ТС-посте я не случайно упомянул, может ли РФС быть «надстройкой» поверх локальной файловой системы, ибо практически такое определение я встречал на нескольких ресурсах. Таки верно ли утверждение, что, к примеру, та же NFS является сетевой абстракцией поверх существующей ФС? [http://www.ibm.com/developerworks/linux/library/l-network-filesystems/index.h... Если да, то нужно ли форматировать раздел под NFS, или NFS это всё таки лишь протокол + набор некоторых правил, определяющий поведение файлов и каталогов в такой ФС?

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

NFS это всё таки лишь протокол

Угу.
gluster не щупал, не знаю.

пособие не посоветую.

смотри. что такое файловая система и из чего она состоит? фс это:

— протокол доступа. чаща всего, фс реализуют интерфейс в котором ключевой элемент абстракции — файл. но не обязательно. единственное что есть общего в интерфейсе всех файловых систем которые я знаю — возможность записать и прочитать все данные некоей единицы хранения, чаще всего файла, потому что если это не файл, то систему не называют «файловой», хотя суть от этого названия не сильно меняется, — определенные базы данных и фс очень похожи как по интерфейсу, так и по методам хранения данных. есть несколько относительно стандартных протоколов, самый пожалуй популярный из них — так называемые posix-compatible системы, в которых есть файл, иерархия директорий, и привычные юникс-права (если без подробностей). в юниксе как правило такие системы работают как «модули» для VFS, подсистема ядра VFS транслирует стандартные POSIX системные вызовы, такие как open(2), readlink(2) или chmod(2) в вызовы понятные драйверу фс. в таких случаях пользователь может такую фс смонтировать и работать с ней как с любой другой, и весь софт будет знать как к ней обращаться. однако есть и другие интерфейсы, и тогда только софт написанный с поддержкой этой фс сможет в нее писать/читать — многие distributed fs именно такие, потому что а) хранятся там специфические данные, нужные только специализированным приложениям и б) они имеют специальные оптимизации которые делают определенные виды доступа невозможными (читай — дико медленными). например, очень часто в файл нельзя писать рандомно, только в конец. или нельзя вообще — можно писать и читать только файл целиком. однако всего найдутся инетерсные люди которые захотят с ними все равно работать как с обычной фс, хоть и ограниченной — так появляются модули эмулирующие посикс для них, чаще всего в виде fuse модулей, и используя их ты сможешь ее смонтировать, а не рабочие операции будут либо неэффективны (попытка записать в середину файла == считать весь файл && записать модифицированные файл && удалить старый). самое страшное тут то что разные фс дают разные гарантии (семантику), читай ту статью что я залинковал. и это даже для локальных систем проблема, а в распределенных вообще полный пиздец на кождом шаге, я например фиксил hdfs после того как хадуп неправильно записал метаданные партиции. абстракции текут =/

— механизм маппинга интерфейса в реальные данные на хранилище (чаще всего диск). т.е. программа запросила «данные файла Х», где и как взять эти данные? чаще всего нам надо считать определенные блоки с «блочного хранилища» (диск, раздел на диске, рейдмассив, lvm, san lun, — причем это может быть даже файл на другой смонтированной файловой системе, ты вполне можешь у себя в хомяке сделать файл, и форматнуть его в ext4 например, и смонтировать через losetup). однако помимо блочного устройства это может быть и другая фс, в таком случае мы маппим обьекты одной фс в обьекты другой. блочные устройства тоже могут быть локальные (обращения к ним через block layer в ядре, читаем/пишем определенные блоки), так и распределенными — у них свой сетевой протокол доступа. разумеется тогда драйвер фс сам должне знать как к таким блочным устройствам обращаться.

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

классические локальные фс типа ext или xfs хранят данные на локальных блочных устройствах. их можно заставить писать на сетевые блочные устройства, такие как iscsi lun или rados, если через специальный драйвер сделать их доступными как локальные устройства. они не имеют сетевого интерфейса, только локальный. NFS это просто сетевой интерфейс для доступа к локальной фс. т.е. я на хосте экспортирую свою директорию, скажем, /mnt/share, и пользователи могут эту фс смонтировать по сети, писать туда данные, и у всех будет общий view данных (если забыть про локинг и локальное кеширование). не важно, что такое /mnt/share — это может быть каталог в руте, в который в /mnt/share/a смонтирована лакольная ext4, а в /mnt/share/b — cephfs, nfs это просто протокол доступа по сети, nfs просто маппит в локальные обьекты типа файл и директория, использует стандартный posix-уровень через vfs. если ты виндузятник, думай про nfs как про «сетевую папку» (технически это реализовано другим похожим на nfs протоколом, cifs). к распределенным фс nfs и cifs в общем случае отношения не имеет никакого.

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

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

по типу доступа (интерфейсу) тоже есть варианты. некоторые экспортируют интрефейс похожий на nfs. другие имеют свой собственный протокол и требуют поддержки от приложения. почти все имеют модуль fuse позволяющий смонтировать ее локально как posix-систему.

главное чему уделяется больше всего внимания в distributed системах вообще — координация записей, отказоустойчивость и работа при партиционировании. потому что проблемы гарантированно будут, а обеспечить все и сразу невозможно, — надо выбирать приемлемые для целевой нагрузки trade-offs.

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