Запись в удаленный файл: когда действительно возвращается write ()? - PullRequest
Новая
       33

Запись в удаленный файл: когда действительно возвращается write ()?

4 голосов
/ 10 октября 2011

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

Что я хочу понять, это:
Когда я write() (или pwrite()), когда именно возвращается вызов write?

Я вижу три возможности:

  1. write возвращается сразу после постановки в очередь операции ввода-вывода на стороне клиента:
    В этом случае write может вернуться до того, как данные фактически покинули клиентский узел (если вы выполняете запись на локальный жесткий диск, тогда вызов записи использует отложенные записи, когда данные просто помещаются в очередь для записи. Но это также происходит когда вы пишете на удаленный жесткий диск?). Я написал тестовый сценарий, в котором я записываю большую матрицу (1 ГБ) в файл. Без fsync он показал очень высокие значения пропускной способности, тогда как с fsync результаты выглядели более реалистичными. Похоже, что это может быть использование отложенных записей.

  2. write возвращается после передачи данных в буфер сервера:
    Теперь данные находятся на сервере, но находятся в буфере в его основной памяти, но еще не хранятся на жестком диске. В этом случае время ввода-вывода должно зависеть от времени передачи данных по сети.

  3. write возвращается после фактического сохранения данных на жестком диске:
    Что, я уверен, не происходит по умолчанию (если только вы не пишете действительно большие файлы, которые приводят к тому, что ваша память заполняется и в конечном итоге очищается и так далее ...).

Кроме того, я хотел бы убедиться в следующем:
Может ли произойти ситуация, когда программа завершает работу, когда никакие данные фактически не покидают клиентский узел, так что сетевые параметры, такие как задержка, пропускная способность и пропускная способность жесткого диска, вообще не учитываются во время выполнения программы? Представьте, что мы не делаем fsync или что-то подобное.

РЕДАКТИРОВАТЬ: я использую параллельную файловую систему pvfs2

Ответы [ 2 ]

3 голосов
/ 10 октября 2011

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

Как говорится, «В компьютерных науках есть только две сложные вещи: недействительность кэша и именования и ошибки« один за другим ».

Если файловая система должна быть POSIX-совместимой, вынужно изучить семантику POSIX fs и посмотреть, как она поддерживается fs при достижении хорошей производительности (в качестве альтернативы, какие части семантики POSIX она пропускает, например NFS).Интересно, что семантика POSIX fs восходит к 1970-м годам, и почти ничего не говорится о том, как поддерживать сетевые файловые системы.

Я не знаю конкретно о pvfs2, но обычно для того, чтобы соответствовать POSIX и обеспечить достойную производительность, вариант 1 может использоваться вместе с каким-то протоколом когерентности кэша (что, например, делает Luster).Для fsync () данные должны быть переданы на сервер и зафиксированы в стабильном хранилище на сервере (дисках или в кэше записи с батарейным питанием), прежде чем fsync () вернется.И, конечно, у клиента есть некоторое ограничение на количество грязных страниц, после чего он будет блокировать дальнейшую запись () в файл, пока некоторые из них не будут переданы на сервер.

2 голосов
/ 10 октября 2011

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

Следующее все взято из Linux.Solaris и другие могут отличаться.

Некоторые важные open флаги O_SYNC, O_DIRECT, O_DSYNC, O_RSYNC.

Некоторые важные флаги монтирования для NFS: ac, noac, cto, nocto, lookupcache, sync, async.

Некоторые важные флаги для экспорта NFS: sync, async, no_wdelay,И, конечно, флаги монтирования файловой системы, которую экспортирует NFS, также важны.Например, если вы экспортировали XFS или EXT4 из Linux и по какой-то причине вы использовали флаг nobarrier, потеря питания на стороне сервера почти наверняка приведет к потере данных.

...