What about O_DIRECT | O_SYNC options in linux's open()?
Unix’s file durability problem
31–40 of 161 posts
Re: Unix’s file durability problem
#32One of the engineers at Google took the time to figure this out, and updated the page out code in the Linux kernel they were using so that the "correct" steps were known if you had to know your data was on disk. It was discussed on LKML as I recall but considered "not generally useful" and I doubt it made it into the main sources. One of the interesting things about writes is that they disrupt reads more significantl…
Even DRAM will be slowest on a random read/write 50% test (it has read-to-write and write-to-read penalties; admittedly these will be dwarfed by precharge/activate penalties, but still, mixing reads and writes will make things worse.)
Re: Unix’s file durability problem
#33Is it just "Unix"? What if fsync returns when the hardware indicates that it has completed a write, but it's actually in some drive controller cache for a few moments more?
Re: Unix’s file durability problem
#34Earlier quoted context omitted.
I wonder what the implications of making an SQLite filesystem would be.
If you then expose that file system through a POSIX file system API, you have all of the same issues of underspecified or unclear behaviour that the article mentions.
If I were designing a userland from the ground up, I'd probably give processes a transactional MVCC object store, and make guarantees about that; and then implement a "POSIX compatibility layer" file system API in terms of that, but explicitly say that none of the same guarantees from the object-store layer apply.
Some days I really do wish we weren't so inured to the particular 50-year-old systems-programming abstractions.
Re: Unix’s file durability problem
#35Earlier quoted context omitted.
Backups do not solve the problem of not knowing whether data you just wrote to disk will still be there in the event of a power outage or system crash. You know, before a backup has a chance to run. Sure, those events should be extremely rare but that doesn't mean that we can or should just ignore it, at a large enough scale even extremely improbable events are guaranteed to happen.
Backups do not solve the problem of not knowing whether data you just wrote to disk will still be there in the event of a power outage or system crash. It's not a "problem", it's just reality. You can't predict when exactly the crash will occur relative to the disk write or backups.
The OP has nothing to do with backups. fsync(2) and friends are also necessary to ensure correct ordering of writes to disk, which in some ways is more important than ensuring that the data is actually committed. If certain writes aren't written in the order expected, then applications lose crash consistency and now you have corrupt data, not just missing data.
Re: Unix’s file durability problem
#36I don't see why you would have to fsync the "parent of the directory", too. That may not be explicitly specified, but it works just this way:
Everything is a file ("object"), whether it's a standard file, or a directory. If you create a new file, you want two things synced: the contents of the file, and the linking of the file (that is the pointer from the directory in which you created the file, to the file object). If you don't sync the link you may not be able to find the file again, even though it was synced to the disk just fine. (It's just how git works btw.)
The link to the file is part of the directory object's contents. That's why the directory needs to be synced.
There is no need to sync the "parent of the directory" because that was never modified.
Re: Unix’s file durability problem
#37Earlier quoted context omitted.
If you then expose that file system through a POSIX file system API, you have all of the same issues of underspecified or unclear behaviour that the article mentions.
If I were designing a userland from the ground up, I'd probably give processes a transactional MVCC object store , and make guarantees about that; and then implement a "POSIX compatibility layer" file system API in terms of that, but explicitly say that none of the same guarantees from the object-store layer apply. Some days I really do wish we weren't so inured to the particular 50-year-old systems-programming abstr…
Microsoft actually tried something similar with WinFS [0] in the 00's, but the project failed.
Re: Unix’s file durability problem
#38Yet another example about how the filesystem, and its POSIX realization, is in fact a horrible abstraction.
I don't think there is anything wrong with the POSIX file system API. Two things:
- I think it's mainly the modern file systems like Btrfs and I think partly also ext4, which introduced a shift in paradigm, which broke old applications (or at least broke their performance, for example dpkg).
- We're talking about a hierarchical file system, meaning it's easy for humans to find data, but terrible for machines because they must hunt pointers to get to files. Similar problem for syncing a bunch of logically connected files if they are not stored in a single directory. (How do you atomically commit multiple changes across directories?)
What would be a better abstraction or non-abstraction (that's still a hierarchical file system)?
Re: Unix’s file durability problem
#39Is it just "Unix"? What if fsync returns when the hardware indicates that it has completed a write, but it's actually in some drive controller cache for a few moments more?
If you care about these types of things, you can tell the drives to not cache writes.
Re: Unix’s file durability problem
#40We needed this recently when doing some custom filesystem work, ended up patching our kernel with something we found in a discussion from lkml.