Я пытаюсь разработать приложение, которое будет работать на нескольких компьютерах, связанных с общим хранилищем Luster, и выполнять различные действия, включая, но не ограничиваясь:
- Добавление данных в файл.
- Чтение данных из файла.
- Чтение и запись в файл, изменение всего его содержимого с определенным смещением.
- Чтение и запись в файл,изменение его содержимого с определенным смещением.
Как видите, базовый ввод-вывод можно пожелать.
Так как для большинства из них это происходит одновременно, мне понадобится какая-то блокировка для безопасного выполнения различных записей, но я видел, что Luster по умолчанию не поддерживает flock (2) (и яЯ не уверен, что хочу использовать его вместо fcntl (2), я думаю, что я буду использовать, если он дойдет до этого), и я не видел ничего о fcntl (2), чтобы подтвердить его поддержку.
В результате его изучения я прочитал много статей об оптимизации ввода / вывода с использованием Luster, но они обычно объясняют, как работает структура их аппаратного / программного / сетевого, а не объясняют, как это делается в коде.
Итак, можно ли использовать fcntl (2) с Luster?Должен ли я использовать это?Если нет, каковы другие альтернативы, позволяющие различным клиентам одновременно выполнять модификации данных?
Или это вообще возможно?(Я видел в билетах Luster, что mmap возможен, поэтому fcntl тоже должен работать (без логики за утверждением), но могут быть ограничения, о которых я хотел бы знать.)
Я буду продолжатьнаписать тестовое приложение, чтобы проверить его, но я решил, что мне все равно следует спросить, есть ли лучшие альтернативы (или если есть ограничения его функциональных возможностей, о которых я должен знать, так как мой тест будет ограничен, и мы не хотимнеизвестные ограничения, чтобы стать проблемой позже в процессе разработки).
Спасибо,
Редактировать: LustreOne правильно ответил на базовый вопрос, здесь я даю более конкретную информацию о моем случае использования, чтобы позволить людям добавлять соответствующую дополнительную информацию о Luster одновременноaccess.
Клиенты Luster будут серверами для других приложений.Каждый из клиентов этих приложений будет иметь свой собственный набор файлов, но мы хотим, чтобы клиенты могли одновременно входить в свое клиентское пространство с нескольких компьютеров, и для этого нам нужно разрешить одновременное чтение и запись файлов.
Это, однако, всегда будет довольно небольшой процент от общего числа операций ввода-вывода.
Хотя в ответе LustreOne были даны действительно интересные идеи, не многие из нихприменимы к этому варианту использования (или, скорее, они применимы, но сложность всей системы может оказаться нежелательной для влияния на производительность).
То есть для варианта использования, рассматриваемого в настоящее время, яЯ уверен, что это может быть очень полезно для некоторых, и для нас самих в дальнейшем.Однако то, что мы ищем прямо сейчас, - это более простой способ позволить двум узлам или потокам узел, отвечающий на два запроса, изменить данные, чтобы пропустить один и обнаружить конфликт, эффективно предотвращая заинтересованного клиента.
Я полагал, что блокировка файла будет достаточной для этого варианта использования, но у него было предпочтение байтовой блокировки, поскольку некоторые наиболее важные файлы добавляются без остановки некоторыми клиентами и читаются / изменяются до конца.другими.
Однако, судя по тому, что я понял из ответа LustreOne:
При этом не существует строгих требований к этому, если ваше приложение знает, что оно делает.Luster уже будет поддерживать неперекрывающиеся записи согласованными и может обрабатывать одновременные записи O_APPEND.
Более поздним случаем уже управляет Luster из коробки.
Любое мнение о том, что может быть лучшими альтернативами?Будет ли достаточно использовать простую функцию flock () для полного файла?
Обратите внимание, что некоторый файл также будет иметь индекс, который можно использовать для определения доступности данных без блокировки какого-либо файла данных, будут ли они использоваться или блокируются байтами достаточно быстро, чтобы мы могли избежать увеличения размера кодовой базы для поддержки обоих случаев?
Последнее упоминание о mmap.Я почти уверен, что он не очень подходит для нашего варианта использования, так как у нас так много файлов и много клиентов, поэтому OST не сможет много кешировать, но чтобы быть уверенным ... будет ли он использоваться, и если да,как?^^
Извините за столь многословие, это одна из моих плохих черт.: /
Хорошего дня,