Вопрос или проблема
Я редактировал smb.conf и мне пришло в голову, что
oplocks = no
level2 oplocks = no
это потому, что резервное решение сервера получает доступ к общим файлам не через модуль файловой системы cifs. Что привело к полупарадоксальному вопросу:
Может ли smbd предоставлять файлы из не смонтированной файловой системы (чтобы все получили к ней доступ через демон), чтобы мы могли включить oplocks?
(Через минуту размышления: или, я полагаю, добавить еще один слой перенаправления и неэффективности: добавить виртуальную машину, запускать smbd из виртуальной машины, не запускать резервные копии в виртуальной машине, заставить хост монтироваться через cifs и создавать резервные копии через хост, а клиенты подключаться к общим ресурсам виртуальной машины.)
Глоссарий и фон:
- Оппортунистические блокировки, “oplocks”, это функция SMB, которая позволяет клиентам кэшировать директории и файлы локально, улучшая производительность чтения и записи. Oplocks ортогональны блокировкам. Оппортунистические блокировки, как правило, автоматически предоставляются серверами SMB. Сервера SMB могут “разрушить” oplock, уведомляя клиента, что он больше не может действовать на своей локальной копии и должен сообщать о несообщенных записях, после чего клиент выполняет чтение и запись через сервер.
- Oplock уровня 1 позволяет клиенту кэшировать чтения и записи. До разрушения этот oplock предоставляет эксклюзивный доступ клиенту. “
oplocks = no” отключает oplocks уровня 1. - Oplock уровня 2 позволяет клиенту кэшировать для чтения. До разрушения этот oplock предоставляет доступ к чтению (потенциально) множеству клиентов. “
level2 oplocks = no” отключает oplocks уровня 2. - Существуют дополнительные типы oplocks, но они не охватываются в рамках этого вопроса. Чтобы узнать больше о реализации oplocks в Samba, см. ref.
- Сервер SMB предоставляет файлы в виде “общего ресурса”.
Если сервер smbd предоставил файл (директорию или другой тип потока байт) с oplock из смонтированной файловой системы, файловая система “под” общим ресурсом может читать или записывать файл и выводить его из синхронизации с кэшированным файлом клиента. Обычно это происходит при резервном копировании файла, который изменяется в кэше клиента. Другим общим случаем является демон, который обновляет файл журнала, но кэшированная копия клиента не обновляется. Поскольку такие доступы типичны, я постоянно отключал оба типа oplocks для всех настроек smbd.
Однако, если все доступы к общей файловой системе выполняются через smbd (используя, например, клиенты Windows, smbclient или тип файловой системы cifs для монтирования), тогда oplocks разрываются точно тогда, когда это необходимо для всех модификаций файловой системы. Это предполагает необходимость в том, чтобы smbd предоставлял файлы из несмонтированной файловой системы, чтобы smbd мог организовать решение проблемы читателей-писателей без “невидимых читателей” или “невидимых писателей”, нарушающих согласованность.
Может ли smbd предоставлять файлы из несмонтированной файловой системы
Нет.
Однако на ум приходят два возможных предложения
-
Смонтировать общую файловую систему на самом сервере и указать вашему решению резервного копирования ссылаться на нее, а не на основное дерево файлов
-
Игнорировать проблему. Резервное копирование – это (в идеале) моментальный снимок во времени. Имеет ли действительно значение, являются ли записи актуальными или кэшированы на клиенте? Результат в любом случае – частично измененный файл; просто в одном случае он обновлен чуть более недавно
Ответ или решение
Samba – это программное обеспечение, которое предоставляет услуги совместного использования файлов и принтеров с использованием протокола SMB/CIFS. Один из важных аспектов его работы – это поддержка оппортунистических блокировок (оплоков). Оппортунистические блокировки позволяют клиентам локально кэшировать директории и файлы, что улучшает производительность операций ввода-вывода. Однако существуют ситуации, когда стандартная функциональность оплоков может привести к проблемам с целостностью данных, особенно в контексте резервного копирования. Давайте более подробно рассмотрим этот вопрос в применении к вашей ситуации.
Теория
Основная задача оплоков – синхронизация доступа к файлам. Когда клиент получает оппортунистическую блокировку, он может кэшировать файлы локально и выполнять операции, не обращаясь непосредственно к серверу, пока сервер не отзовет блокировку. Однако, если доступ к файлу осуществляется не через протокол SMB, например, посредством других процессов на сервере, это может привести к несоответствиям между состоянием файла на клиентах и сервере. Это особенно критично для резервных копий, где важно иметь точное и актуальное состояние файловой системы на момент копирования.
Пример
Представьте, что у вас есть сервер с установленной Samba, и вы хотите использовать оплоки для улучшения производительности. В стандартной конфигурации вы устанавливаете oplocks = yes и level2 oplocks = yes, что позволяет клиентам производить кэширование данных. Однако резервная копия выполняется напрямую на сервере, не используя Samba. В этом случае файлы могут быть изменены резервным копированием, что не синхронизировано с клиентскими кэшами. Это приводит к потенциальной потере данных или их ошибочному дублированию.
Применение
Ваш вопрос о возможности работы smbd с файловыми системами, которые не монтируются напрямую на сервере, напрямую затрагивает данную проблему. Ответ: "Нет, невозможно". smbd требует монтирования файловой системы, чтобы иметь возможность управлять доступом и правильно обрабатывать запросы клиентов. Хотя есть несколько путей обхода проблемы:
-
Решение через виртуализацию: Вы можете создать виртуальную машину, где будет запущен
smbd, и настроить все операции, включая резервное копирование, через него. Это изолирует доступ к файловой системе и позволяет использовать оплоки без риска асинхронного доступа. -
Изменение логики резервного копирования: Монтируйте файловую систему на сервере и укажите резервному копированию использовать смонтированные ресурсы через Samba. Это позволит разные процессы работать последовательно и предотвратит конфликтные ситуации с кэшированием.
-
Игнорирование проблемы для резервного копирования: В некоторых случаях, вопрос о необходимости актуальности данных для резервного копирования может быть не столь критичным. Если резервное копирование рассматривается как мгновенный снимок, небольшие отличия, возникшие в следствии кэширования, могут быть допустимы.
Заключение
Для решения проблемы целостности данных при использовании оппортунистических блокировок крайне важно обеспечить единственно возможный путь доступа ко всем операциям с файлами через smbd. Все остальные формы доступа должны быть исключены или тщательно интегрированы в общий поток операций. Это единственный способ гарантировать, что оплоки будут работать корректно, и любые изменения файлов будут своевременно зафиксированы. Если это невозможно реализовать в имеющейся инфраструктуре, возможно стоит рассмотреть другие подходы к организации файловых операций или использования аналогов Samba, которые удовлетворяют ваши конкретные требования.