>Таки абстрактных? И таки абсолютно не коррелирующих со структурами данных в файловой системе?Таки астрактных. И одно время использовались только plain locks для защиты и данных и мета-данных. потом в в процессе оптимизации и улучшения маштабируемости - их разделили и добавили 3й (полностью абстрактный) тип локов - glimpse - задача которого просто определять кто является "владельцем" EOF и от кого это можно получить (только не надо говорить что это отображение i_size - это совсем не так)
Скажу даже больше - metadata-id - которым служит inode-no, отношения к идентификаторам на storage серверах никакого не имеет. там используется внутренная адресация внутри storage node - называется это LSM.
Так что resource_id для обращения к серверам с данными - совсем другой чем по обращению к мета-данным серверов.
>на клиенте в 2.x используются полностью абстрактные идентификаторы - FID
> И по каким же алгоритмам производится распределение этих идентификаторов? Какие же данные используются в этих алгоритмах в качестве входных и выходных параметров?
FID аллоцируется на клиенте исходя из пула который был выделен данному клиенту сервисом FID'ов.
Этот FID используется в мета-дата операциях, в всех операциях связаных с data - фигурирует номер объекта и
идентификатор storage сервера, который был назначен файлу при создании файла.
запрашивание что extent что glimpse, что plain/bitlock lock производится через один вызов.
ldlm_enqueue_lock($server, $resource_id, $type, &callbacks, &data);
где-то так по памяти - лень код лесть.
>Отлично. Только на их основании вы и будете рулить локами?
Да (это не считая того что на GEOM уровне доступно "чуть" больше информации)
>А как же вы поступите с файловой системой, у которой кэш есть?
буквы "O_DIRECT" в сообщении выше не заметили? слово sync() которое там упоминалось с целью скинуть весь кэш на storage при обнаружении конфликта?
