Что такое соответствие posix для файловой системы?

Ответ 1

В области "требуется семантика файловой системы POSIX", что обычно подразумевается:

• позволяет иерархические имена файлов и разрешения (.,..,...)
• поддерживает по крайней мере семантику, близкую к открытой
• разрешения umask/unix, 3 файла времени
• поддержка 8-битного байта
• поддерживает атомные переименования в той же файловой системе
• fsync()/dirfsync() durability gurantee/ограничение
• поддерживает многопользовательскую защиту (файл изменения размера возвращает 0 байт, а не мусор)
• переименовать и удалить открытые файлы (Windows этого не делает)
• имена файлов, поддерживающие все байты рядом с '/' и \0

Иногда это также означает поддержку symlink/hardlink, а также имена файлов и 32-битные указатели файлов (минимум). В некоторых случаях он также используется для ссылки на конкретные функции API, такие как fcntl() блокировка, mmap() или truncate() или AIO.

Ответ 2

Ответ на ваши вопросы очень объективно:

1. все ли файловые системы должны быть совместимы с posix? Вообще-то нет. Фактически POSIX определяет некоторые стандарты для операционных систем в целом. Хорошо, но не нужно.

2. требуются ли приложения, совместимые с posix? Нет.

3. существуют ли какие-либо файловые системы non posix? HDFS (файловая система hasoop)

Ответ 3

Когда я думаю о соответствии POSIX для распределенных файловых систем, я использую общий стандарт, согласно которому распределенная файловая система совместима с POSIX, если несколько процессов, работающих на разных узлах, видят то же поведение, что и при использовании на одном и том же node, используя локальная файловая система. Это в основном имеет два значения:

• Если система имеет несколько буферных кешей, она должна обеспечивать согласованность кеша.
  • Различные механизмы для этого включают блокировки и лизинг. Примером неправильного поведения в этом случае будет писатель, который успешно пишет на одном node, но затем читатель на другом node получает старые данные.
  • Обратите внимание, что если автор/читатель независимо друг от друга участвуют в гонке, что не существует правильного определенного поведения, потому что они не знают, какая операция будет происходить в первую очередь. Но если они координируют друг с другом с помощью какого-то механизма, такого как обмен сообщениями, тогда было бы неправильно, если писатель завершит (особенно если он выдает вызов sync), отправляет сообщение читателю, который успешно принят читателем, а then читатель считывает и получает устаревшие данные.
• Если данные чередуются на нескольких серверах данных, чтение и запись, которые охватывают несколько полос, должны быть атомарными.
  • Например, когда читатель читает полоски в то же время, что и писатель пишет по тем же самым полосам, читатель должен либо получать все полосы так, как они были до записи или всех полос, как они были после записи. Некорректное поведение было бы для читателя получить некоторые старые и некоторые новые.
  • В отличие от вышеизложенного, это поведение должно работать корректно, даже когда писатель/читатель гоняется.

Хотя мои примеры были прочитаны/записаны в один файл, правильное поведение также включает запись/запись в один файл, а также чтение/запись и запись/запись в иерархическое пространство имен с помощью таких вызовов, как stat/readdir/mkdir/разъединить/др.