Клиенты NFS повторно проверяют блоки кэша при доступе, оценивая T-Tc <t. Если это не удается, он отправляет вызов getattr на сервер NFS с запросом последней Tmodified штампа соответствующего файла.
AFS повторно проверяет свои файлы кэша после периодического времени T, при открытии или перезапуске.
Что происходит, когда эти вызовы повторной проверки теряются в сети? Когда мы предполагаем жесткое монтирование с помощью NFS, блокируется ли клиент NFS при ожидании ответа на вызов getattr, или мы можем пропустить эту проверку на время, чтобы продолжить работу?
То же самое для AFS, блокируется ли ожидание проверки, или мы можем продолжить работу?
Модель согласованности кэша AFS, принятая OpenAFS и АуриСторФС немного отличается от того, что вы описываете в вопросе.
Каждый объект, хранящийся в / afs, имеет как
«Номер версии данных» для объекта увеличивается каждый раз при изменении данных объекта, но не при изменении метаданных.
Клиенту, также известному как диспетчер кеша, разрешено кэшировать данные и метаданные для объекта, но разрешено считать их актуальными только в том случае, если он получил * обещание обратного вызова "от файлового сервера. Это время жизни обещание обратного вызова который определяет, как часто диспетчер кеша должен передавать FetchStatus RPC файловому серверу. Пока обещание обратного вызова не истекло, диспетчер кеша может использовать кэшированные данные. Если файловый сервер выдает Перезвони RPC к диспетчеру кеша, обещание отменяется, и диспетчер кеша должен получить обновленную информацию о состоянии.
Канал обратного вызова от файлового сервера к диспетчеру кеша в исходной файловой системе Andrew и OpenAFS не аутентифицируется. Поэтому его нельзя использовать для передачи фактических данных или изменения метаданных. Диспетчер кеша должен получить его через собственное соединение, которое потенциально аутентифицировано и зашифровано. Одним из отличий AuriStorFS от более ранних вариантов AFS является использование безопасных каналов обратного вызова.
Как только диспетчер кеша получает последние метаданные, он может сравнить текущий номер версии данных с версией данных, которые были кэшированы. Если версия не изменилась, кешированные данные все еще действительны. В противном случае устаревшие данные должны быть удалены из кеша, а обновленные данные извлечены.
Одно из свойств модели согласованности кэша AFS заключается в том, что файловая система рассматривается как платформа для сериализованных сообщений. Существует фундаментальное требование: если машина A активно использует файл, а машина B хочет изменить файл, а затем отправить внешнее сообщение на машину A, чтобы прочитать обновленный файл, обновление файла должно прибыть до внешнего сообщения. . Это свойство гарантируется тем, что все обещания обратного вызова нарушаются до того, как RPC, изменивший файл, перейдет к издателю.
Вы подняли вопрос о том, что происходит при отказе соединения между клиентом и файловым сервером. Файловый сервер будет пытаться в течение некоторого времени отправить RPC обратного вызова, но не будет блокировать на неопределенный срок. Вместо этого он помещает в очередь отложенное сообщение обратного вызова для клиента, которого он не может достичь, и завершает RPC для эмитента. В следующий раз, когда клиент, потерявший соединение, свяжется с файловым сервером, все его операции будут заблокированы до тех пор, пока не будут доставлены все отложенные обратные вызовы.
В течение периода времени, когда соединение было потеряно, клиент может попытаться связаться с другим файловым сервером, который поддерживает реплику данных. Если их нет и том, к которому осуществляется доступ, жестко смонтирован, клиент будет заблокирован на неопределенный срок. Если он не смонтирован жестко, то для всех выданных сетевых RPC истечет тайм-аут, и ошибка будет возвращена приложению-издателю.
Я надеюсь, что это удовлетворительно описывает поведение файловых систем семейства AFS.