Блокировка блеска файла для одновременного доступа

Question

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

• Добавление данных в файл.
• Чтение данных из файла.
• Чтение и запись в файл, изменение всего его содержимого проходят определенное смещение.
• Чтение и запись в файл, изменение его содержимого с определенным смещением.

Как видите, базовый ввод / вывод можно пожелать.

Поскольку в большинстве случаев это происходит одновременно, мне понадобится какая-то блокировка для безопасного выполнения различных записей, но я видел, что Luster по умолчанию не поддерживает flock(2) (и я не уверен, что хочу использовать его вместо fcntl(2), я думаю, что я буду использовать, если он до него дойдет), и я не видел ничего о fcntl(2), чтобы подтвердить его поддержку.

Его исследование в основном привело к тому, что я прочитал много статей об оптимизации ввода / вывода с использованием Luster, но они обычно объясняют, как работает структура их аппаратного / программного / сетевого, а не объясняют, как это делается в коде.

Итак, я могу использовать fcntl (2) с блеском? Должен ли я использовать это? Если нет, каковы другие альтернативы, позволяющие различным клиентам одновременно выполнять модификации данных?

Или это вообще возможно? (Я видел в билетах Luster, что mmap возможен, поэтому fcntl тоже должен работать (без логики в выражении), но могут быть ограничения, о которых я хотел бы знать.)

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

Спасибо,

Редактировать: LustreOne правильно ответил на базовый вопрос, здесь я даю более конкретную информацию о моем случае использования, чтобы позволить людям добавлять соответствующую дополнительную информацию о параллельном доступе Luster.

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

Это, однако, всегда будет довольно небольшой процент от общего количества операций ввода-вывода.

Хотя в ответе LustreOne были даны действительно интересные идеи, не многие из них применимы к этому варианту использования (точнее, они применимы, но сложность всей системы может оказаться нежелательной для воздействия на производительность).

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

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

Однако, судя по тому, что я понял из ответа LustreOne:

Тем не менее, нет строгих требований к этому, если ваше приложение знает, что оно делает. Lustre уже будет поддерживать согласованность неперекрывающихся записей и может обрабатывать одновременные записи O_APPEND.

Последним делом уже занимается Luster из коробки.

Любое мнение о том, что может быть лучшими альтернативами? Будет ли достаточно использовать простой flock() для полного файла?

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

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

Извините за то, что так многословен, это одна из моих плохих черт.:/

Хорошего дня,

Answer 1

Вы должны смонтировать все клиенты с опцией монтирования "-o flock", чтобы включить глобально согласованную блокировку. Тогда flock() (и я думаю, что fcntl() блокировка) будет работать.

Тем не менее, нет строгих требований к этому, если ваше приложение знает, что оно делает. Lustre уже будет поддерживать согласованность неперекрывающихся записей и может обрабатывать одновременные записи O_APPEND. Однако, поскольку Luster должен выполнять внутреннюю блокировку для добавлений, это может значительно снизить производительность записи, если множество клиентов одновременно добавляют один и тот же файл. (Обратите внимание, что это не проблема, если добавляется только один клиент).

Если вы пишете приложение самостоятельно, есть много вещей, которые вы можете сделать, чтобы повысить производительность: - попросите некоторый центральный поток назначить "номер слота записи" каждому записывающему устройству (по сути, увеличивающееся целое число), а затем клиент записывает смещение = размер записи * номер слота. Помимо присвоения номера слота (что может быть выполнено партиями для повышения производительности), между клиентами нет конфликта. В большинстве приложений HPC потоки используют ранг MPI в качестве номера слота, поскольку он уникален, и потокам на одном и том же узле обычно назначаются смежные слоты, так что Luster может дополнительно агрегировать записи. Это не сработает, если вы используете модель производителя / потребителя, где потоки могут создавать переменное число записей. - заставить IO записывать размер, кратный 4 КБ, чтобы избежать конфликта между потоками. В противном случае клиенты или серверы будут вынуждены выполнять чтение-изменение-запись для частичных записей в блоке диска, что неэффективно. - В зависимости от того, позволяет ли ваш рабочий процесс это делать или нет, вместо того, чтобы выполнять чтение и запись в один и тот же файл, вероятно, будет более эффективно записать несколько записей в один файл, а затем обработать файл целиком и записать во второй файл. Не то, чтобы Luster не мог выполнять одновременное чтение и запись в один файл, но это вызывает ненужные конфликты, которых можно избежать.