Link Search Menu Expand Document

Mount Write Mode Semantics

experimental

Consistency Model

File System Consistency

Everest mount provides a strong read-after-write consistency model within a single mount point. This means that once a write operation is done, the data is guaranteed to be available for subsequent read operations.

lakeFS Consistency

Local changes are reflected in lakeFS only after the changes are committed. That means that the data is not available for other users until the changes are committed. If, for example, two users mount the same branch, they will not see each other’s changes until they are committed.

Sync local changes to lakeFS

  • As part of commit and diff commands a sync operation will upload all the local changes to a temporary write-branch.

Mount Write Mode File System Behavior

Functionality Limitations

  • Newly created empty directories will not reflect as directory markers in lakeFS.
  • lakeFS allows having 2 path keys that one is a “directory” prefix of the other, for example the following 2 lakeFS keys are valid: animals/cat.png and animals (empty object) but since a file system cannot contain both a file and a directory of the same name it will lead to an undefined behavior depending on the Filesystem type (e.g., dir and dir/file).

File System Behavior

Not Supported:

  • Rename is not supported.
  • Temporary files are not supported.
  • Hard/symbolic links are not supported.
  • POSIX file locks (lockf) are not supported.
  • POSIX permissions are not supported - default permissions are given to files and dirs.
  • A deleted file’s name cannot be used as a directory type later and the same for opposite types (e.g, Not allowed: touch foo; rm foo; mkdir foo;).
  • Calling remove on a directory type will fail explicitly with an error.

Behavior modified:

  • Modifying file metadata (chmod, chown, chgrp, time) will result in noop (the file metadata will not be changed).
  • When calling remove we mark a file as a tombstone using Extended Attributes API’s.
  • Removal is not an atomic operation, calling remove and open at the same time might result in a race condition where the open might succeed.