DAX semantics

Posted May 14, 2019 1:04 UTC (Tue) by gutschke (subscriber, #27910)
Parent article: DAX semantics

If regular file I/O and DAX semantics are mutually exclusive, then setting a flag on the file is going to be an administrative pain. All of a sudden, there is a file that cannot be accessed with "normal" UNIX tools. How about calling "file", "sed", "dd", "tar", or "cp" on a DAX file? These all seem reasonable administrative things to do -- at least whenever the file isn't concurrently opened in DAX mode.

I think, from a usability point of view, having a flag on open() is a lot less surprising for any object that lives inside of the filesystem namespace. I do agree though, that files should lock out incompatible access modes, if they have already been opened in another mode. There is some precedence for that. open() already returns ETXTBSY in similar situations. Currently, that can only happen for write access, but it wouldn't be too far-fetched to also do so for write access of DAX files.

DAX semantics

Posted May 14, 2019 1:13 UTC (Tue) by gutschke (subscriber, #27910) [Link]

$s/write/read/

DAX semantics

Posted May 24, 2019 18:15 UTC (Fri) by mcr (subscriber, #99374) [Link]

I want to echo gutschke's comments about the flag causing standard tools to break. They should continue to work for read-only, as getting good backups depends upon this.
Backups in general are a big issue, I have wanted the VFS layer to provide better access to backups for along time. I would go as far as saying that file systems should be able to turn file contents plus *all* metadata (and extensions, etc.) into POSIX CPIO format directly. (Or, dump format, but I think that is far less standard) The CPIO/TAR/etc. can't be expected to keep up with whatever innovation file system creators are doing. This would significantly free file systems to innovate more, knowing that backup tools would continue to work.