>>Могут работать как на блочном уровне, так и на уровне файлов. В терминах DLM нету понятия файл\каталог и тп.
>>Есть понятие "ресурс" и тип блокировки. Данные это один тип ресурсов; каталоги, имена файлов - другой.
>
>Пожалуйста, не увиливайте от ответа. Для того, чтобы обеспечить корректную работу фс,
>DLM должен с ней взаимодействовать и "знать" про файлы и каталоги,
>или это необязательно? нет не обязательно. DLM работает с понятием "ресурс". в "кластерных" FS - Lustre, Panasas, GFS - такими ресурсами являются метаданные (каталоги и атрибуты inodes) и данные (диапазон смещений от начала файла).
В случае блочного устройства - будет один "ресурс" == диск - и много extent locks каждый на свой offset range.
Причем в случае устройства можно искуственно хранить не смещение с точностью до байта, а просто номер блока.
>Блокировки, конечно, можно ставить и на уровне объектов фс, и на уровне
>блоков, но сути это не меняет. Ключевую роль играет алгоритм определения
>необходимости установки/снятия блокировки.
Меняет. Блокировки на уровне блоков никаким образом не затрагиваю понятие "метаданные" (которыми являются каталоги и зоны блоков выделенных для inode/vnode). метаданные это ровно такие же блоки на блочном устройстве как и блоки данных выделенные для inode.
>
>>Что значит файловая система разработаная под кластер - какой тип кластера имеется ввиду - HA решение или полноценный вычислительный кластер?
>
>А нафига, простите, для HA master-master? Ну, кроме live миграции виртуальных машин?
Для кластеров баз данных к примеру.
Ответа на вопрос "что в вашем понятии кластер" я так и не увидел - я знаю как миниум 3 вещи которые могут подойти под это определение, сдается что возможно еще что-то новое.
