43 ms·

It's pretty common for people with some experience to not understand filesystem nuance - there's quite a bit of it right here in the hn comment section. You'll

It's pretty common for people with some experience to not understand filesystem nuance - there's quite a bit of it right here in the hn comment section. You'll note below I also corrected someone significantly more credentialed than the author of this LWN post. My suggestion to you: Worry less about measuring resumes and more about who is actually correct as a matter of demonstrable fact. If you have actionable questions, ask them. Use facts, not appeals to (frankly not very substantial) authorities.

nh2 3y ago
The throwaway acccount is right. In POSIX, file content data and metadata (directory entries) are separate. Atomicity and durability are separate. It is likely that the LWN post author understands this very well, but omitted this important info from the article. -- I can also understand throwaway's criticism, e.g. on sections like this: > Given this situation, application developers came to rely on what is, on the face of it, a completely reasonable assumption: rename() of one file over another will either result in the contents of the old file, or the contents of the new file as of the time of the rename(). No. There is nothing reasonable about this. This is programming. When you're programming against a spec (POSIX), you don't "make assumptions". You rely only on what it says in the spec. It would be "reasonable" to wish that somebody creates spec that ensures the mentioned rename semantics. But assuming that a spec says something it doesn't is wishful thinking. People are quick to lazy it out, assume, copy-paste, etc, instead of critically thinking "wait, does the code I write here really guarantee the desired effect, e.g. to write my file to disk". Reject assumption-based programming. Go check. Read the docs. That makes good programs. Or, as the throwaway says, rely on "demonstrable fact".
- lxgr 3y ago
  > No. There is nothing reasonable about this. This is programming. When you're programming against a spec (POSIX), you don't "make assumptions". You rely only on what it says in the spec. Are you sure 100% of Linux application developers first and foremost think about POSIX, and never rely on an implementation-defined oddity to get the behavior they need? Hyrum's Law is powerful: "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." > People are quick to lazy it out, assume, copy-paste, etc, instead of critically thinking "wait, does the code I write here really guarantee the desired effect, e.g. to write my file to disk". Exactly. That is a fact of life that Linux kernel developers have to balance with POSIX.
- aidenn0 3y ago
  > The throwaway acccount is right. > In POSIX, file content data and metadata (directory entries) are separate. Atomicity and durability are separate. > It is likely that the LWN post author understands this very well, but omitted this important info from the article. 1. If the author understands this, then the throwaway is wrong, since they claimed the author didn't know this. 2. The entire point of TFA was that POSIX is underspecified here, so I think they covered it sufficiently; something that worked on FFS didn't work on ext4, and the suggestion is that it should work going forwards, regardless of what POSIX requires.
  - throwaway09223 3y ago
    POSIX isn't underspecified here. rename() has no durability guarantees. That's the answer. "something that worked on FFS didn't work on ext4," As the article notes this is NOT durable on FFS. Early FFS (and early ext) could lose the entire filesystem after a crash. ext2 still can. ext4 is the oddball here. TFA is not framing things correctly.
- thayne 3y ago
  > When you're programming against a spec (POSIX), you don't "make assumptions". You rely only on what it says in the spec. I've been burned several times by relying on what it says in a spec, when the implementation turned out to behave slightly differently.
fao_ 3y ago
> My suggestion to you: Worry less about measuring resumes and more about who is actually correct as a matter of demonstrable fact. It's not about resumes, it's one person who is extremely experienced with the software, versus a nobody. I'll trust the expert every single time.

nh2 3y ago

The throwaway acccount is right. In POSIX, file content data and metadata (directory entries) are separate. Atomicity and durability are separate. It is likely that the LWN post author understands this very well, but omitted this important info from the article. -- I can also understand throwaway's criticism, e.g. on sections like this: > Given this situation, application developers came to rely on what is, on the face of it, a completely reasonable assumption: rename() of one file over another will either result in the contents of the old file, or the contents of the new file as of the time of the rename(). No. There is nothing reasonable about this. This is programming. When you're programming against a spec (POSIX), you don't "make assumptions". You rely only on what it says in the spec. It would be "reasonable" to wish that somebody creates spec that ensures the mentioned rename semantics. But assuming that a spec says something it doesn't is wishful thinking. People are quick to lazy it out, assume, copy-paste, etc, instead of critically thinking "wait, does the code I write here really guarantee the desired effect, e.g. to write my file to disk". Reject assumption-based programming. Go check. Read the docs. That makes good programs. Or, as the throwaway says, rely on "demonstrable fact".

lxgr 3y ago
> No. There is nothing reasonable about this. This is programming. When you're programming against a spec (POSIX), you don't "make assumptions". You rely only on what it says in the spec. Are you sure 100% of Linux application developers first and foremost think about POSIX, and never rely on an implementation-defined oddity to get the behavior they need? Hyrum's Law is powerful: "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." > People are quick to lazy it out, assume, copy-paste, etc, instead of critically thinking "wait, does the code I write here really guarantee the desired effect, e.g. to write my file to disk". Exactly. That is a fact of life that Linux kernel developers have to balance with POSIX.
aidenn0 3y ago
> The throwaway acccount is right. > In POSIX, file content data and metadata (directory entries) are separate. Atomicity and durability are separate. > It is likely that the LWN post author understands this very well, but omitted this important info from the article. 1. If the author understands this, then the throwaway is wrong, since they claimed the author didn't know this. 2. The entire point of TFA was that POSIX is underspecified here, so I think they covered it sufficiently; something that worked on FFS didn't work on ext4, and the suggestion is that it should work going forwards, regardless of what POSIX requires.
- throwaway09223 3y ago
  POSIX isn't underspecified here. rename() has no durability guarantees. That's the answer. "something that worked on FFS didn't work on ext4," As the article notes this is NOT durable on FFS. Early FFS (and early ext) could lose the entire filesystem after a crash. ext2 still can. ext4 is the oddball here. TFA is not framing things correctly.
thayne 3y ago
> When you're programming against a spec (POSIX), you don't "make assumptions". You rely only on what it says in the spec. I've been burned several times by relying on what it says in a spec, when the implementation turned out to behave slightly differently.

fao_ 3y ago

> My suggestion to you: Worry less about measuring resumes and more about who is actually correct as a matter of demonstrable fact. It's not about resumes, it's one person who is extremely experienced with the software, versus a nobody. I'll trust the expert every single time.