4

Do file system or disk drivers support a concept of file system modification fence, like a memory fence in the CPU or shared memory system?

A fence is an instruction that separate memory operations such that globally visible memory accesses after the fence event are not detectable until all those that come before it.

Is such feature available for file content modification (and repertory modification), in an efficient way? Of course a simplistic solution would be wait until all writes are written to stable storage; that however is blocking the application and could be inefficient if many synchronization points are needed. Also, it could cause many small individual writes when one big write (including many writes separated by fences) satisfies the same constrains on fully journalled system, or when the biggest write is guaranteed to be atomic by the disk driver.

Can file system drivers be forced to order writes with file system access fences? Has the concept been explored?

PRECISION

The context of the question is not multiple processes accessing the same files in a racy way but one process saving data in a database such that an interruption of the process (even a computer crash) should leave only one sequence of modifications (between two fences) partially written.

curiousguy
  • 8,038
  • 2
  • 40
  • 58
  • I don't see how the definition of "fence" you cite is applicable to "file system modification" concept. In CPU word, instructions are **indivisible** in the sence how CPU process them: the CPU cannot handle half of the instruction and stop. But only a small write into the file is "indivisible" from the sence of filesystem. What if the first part of the write comes before the file's modification, what FS should do with the rest of write operation? Probably, you want to provide some real (non-abstract) code which demonstrates your purpose. – Tsyvarev Jun 02 '19 at 20:14
  • @Tsyvarev Actually Intel string instructions are not indivisible; they are even interruptible (this is the exception rather than the rule). Most instructions are not interruptible but they don't have a general guarantee of atomicity: arbitrary writes are not atomic on Intel. That however has no relevance for my Q. – curiousguy Jun 02 '19 at 21:12
  • "_But only a small write into the file is "indivisible" from the sence of filesystem_" Indivisible WRT to other processes writing to the same file? That might be solved by file locks or simply convention and is a completely different Q. I don't consider multiple processes writing to the same files in a conflicting way here. I consider stable storage in mass memory in the event the process is stopped. Maybe I should have made that more clear! – curiousguy Jun 02 '19 at 21:17
  • Ok, you are right: indivisible property is not related to the problem. Now I understand your question as searching for `sync`/`fsync` analogue, which is differ in ... in what? Your edit suggests that you seek actually these functions. – Tsyvarev Jun 02 '19 at 21:23
  • 2
    @Tsyvarev I want a non blocking alternative to these functions that additionally doesn't presses the system to flush write caches if it doesn't feel like doing it (the write buffer timer has not expired, or the driver is already busy writing something else, or the disk isn't spinning and the driver would like to keep it that way...). A fence doesn't accelerate previous writes, it says that following writes don't appear before previous writes. In a journalled system, a fence may not even order writing to the journal but instead add a journal entry to order the commits of entries of the journal. – curiousguy Jun 02 '19 at 21:55
  • But yes a primitive implementation of a fence could be a sync. The goal is a to allow ordering of buffers in the driver such that all writes Wi can be in RAM while still knowing that Wj won't be sent to mass storage before Wi is completed for j>i, as if there was a sync between Wi and W(i+1). – curiousguy Jun 02 '19 at 21:58

0 Answers0