https://bugzilla.kernel.org/show_bug.cgi?id=202485 --- Comment #3 from Theodore Tso (tytso@xxxxxxx) --- I do believe we should either fix the man page to document existing practice, or change the kernel. Changing kernel behaviour here going to be a fairly involved, since today the filesystem layer (ext4, btrfs, xfs) is not even informed when a special device file is open, read, written, fsync'ed, etc. Which makes sense; when you write to /dev/tty or /dev/ttyS1, or /dev/sda3, etc., it has nothing to do with the file system where the where the directory entry to said special device file is found. And indeed, if one were to open /dev/sda3, write to it, and then fsync it, the vast majority of user space programs care about the *data* written to /dev/sda3, and not to any associated metadata, such as the permission bits or the modtime of /dev/sda3 being persisted. The history behind fsync(2) was that it was intended for regular files, not special device files, and for database programs in particular. The fdatasync(2) call was added later as an optimization to avoid unnecessary updates to the inode when it was not necessary to be able to access the data blocks that had been written. I am not sure how many legacy Unix implementations implement the semantics that you are hoping for, and I very much doubt there are any user space programs who depend on such a behavior. As such, I suspect it's going to be hard to get most developers to care about implementing this if it's only to be about API semantic purity. If there was a cash-rich, say, Japanese corporation that was going to throw $$$ at a company asking them to fix it, it might happen, if it didn't complicate the implementation; most developers would be far more interested in keeping the VFS layer bug-free and long-term maintainable compared to API semantic purity. Or if *you* really care, it might be an interesting starter project. -- You are receiving this mail because: You are watching the assignee of the bug.
