(It's like NFS getting a bad reputation--especially locking--because Linux's implementation sucked for so many years.)
Huh?
fcntl/lockf works fine over NFS so long as both sides are either using NFS4 or both sides are running NLM (the NFS locking daemon -- i.e. rpc.statd)
Dot-locking also works over NFS, though open(..., O_EXCL|O_CREAT) does not work, nor does flock. Have these worked on other systems, or started working under Linux?
Nor is fsync() what you want - you want an atomic file replace operation.
Yes.
Rename is atomic, and it used to work, but with delayed allocation it may happen before the file is written. So what you want is an atomic file replace operation that does not happen before the data write.
Precisely.
Rename may not be the best option for that - a special file write mode may actually be better. In any case the issue affects both sides - kernel and user space.
NO, NO, NO. write, fsync, close, rename is how you spell "atomically replace this file" in terms of system calls. It does precisely the correct thing on a running system. You yourself admit that it "used to work". It has worked for decades, in fact. (Though before journaling filesystems, all bets were off after a crash.)
That sequence of system calls is how applications tell the kernel to replace the given file. There is no useful interpretation of those system calls that doesn't involve an atomic replacement of the whole file. We don't need a separate system call: we already have the system calls. Nobody executing those system calls wants the dangerous interpretation of rename. At no time did an application developer sit down and think to himself, "I want to tell the kernel to perform an atomic rename, except when the system crashes. In that case, I want a zero-length file." Gods, no. Obviously, the application developer wanted to atomically replace the named file. Filesystems just need to honor the obvious intent of application developers.
So, to bring it back round to the point, isn't the problem that apps break if this undefined behaviour isn't stuck to?
Stop willfully misinterpreting me. The behavior is undefined as far as POSIX is concerned, not undefined in general. It's okay for programs to rely on behavior that goes beyond POSIX. A program that relied on POSIX and nothing else couldn't do anything about crash recovery anyway, since POSIX is silent on the topic of crashes.
There is nothing here to "fix". There is no "flaw".
As for a "good reason" --- programs don't depend on this behavior: users do. Users expect a good filesystem to maintain as many POSIX invariants as possible even after a crash. There is no purely POSIX way for a program to safeguard against a crash.
Your example was one operation: rename B over A. Yes, this is one operation, and yes, POSIX guarantees it will happen atomically
This is the operation salient to the ext4 discussion. The other operation is a distraction. (But for the record, POSIX also guarantees that they happen in order. How could it be otherwise?)
Not quite. I believe XFS and JFS behave the same way as Ext4.
When XFS was first released, there was quite a buzz surrounding it before people realized they'd lose data. XFS, not ext3, would have been the the de-facto Linux standard had the developers not stubbornly refused to fix its dataloss bugs. By the time they finally got around to it (for some cases), there'd already been irreparable damage to XFS's reputation.
The problem is that some applications assume a behavior that is not supported by the POSIX definitions
POSIX is a red herring here. It covers the behavior of a running system, and makes no guarantees about atomicity or durability following a crash. After a crash and as far as POSIX goes, it's perfectly legitimate to overwrite the entire disk with hentai. Every crash recovery technique goes beyond POSIX because POSIX says nothing about crashes.
POSIX doesn't require that the operations be performed in order
It most certainly does! On a running system, if you rename B over A, at no point does any process on the system observe a file called "A" that does not have either the contents of the old A or the contents of B. THIS ATOMICITY IS A FUNDAMENTAL POSIX GUARANTEE.
Filesystems should do their best to honor this guarantee (which always applies on a running system, remember) even when the system crashes. Filesystems don't have to do that according to POSIX. Instead, they should do it because it's a sane thing to do, and doesn't violate anything POSIX guarantees. POSIX is not the arbiter of what a good system should be. It's perfectly reasonable to make guarantees that go beyond POSIX, and every real-world operating system does precisely that. POSIX guarantees are necessary but insufficient for a reasonable system in 2009.
But even then you might end up with a zero byte file, if your system crashes between the close and rename call. (Or between write and close, or doing write, or well anytime after open).
This statement is incorrect. Suppose you want to atomically replace the contents of file "foo". Your application will write a file "foo.tmp", then call rename("foo.tmp", "foo"). At no time on a running system does any process observe a file called "foo" that does not have either the new or the old contents, and this invariant holds true whether or not "foo", "foo.tmp", or any other file has been flushed to the disk.
On the filesystem level, the kernel can actually write the contents of foo.tmp to disk whenever is convenient. The only constraint is that the on-disk name record for "foo" must be updated to point to the new data blocks from foo.tmp only after these data blocks have themselves been written to disk. That's the issue here: without that ordering guarantee, the kernel can write a file's name record before its data blocks. If the system crashes after the name record is written but before the data blocks are, what's observed on the recovered system is a zero-length file.
That's the problem here: the kernel is conjuring out of thin air a zero-length file that never actually existed on a running system.
Forcing applications to call fsync is not only an onerous burden on application developers, but it also reduces performance because it gives the filesystem less freedom than the much looser constraint on rename above.
Bonus points for anyone who can give a realistic use case for DO_NOT_FLUSH_ON_CLOSE
Application configuration files. You don't care that they hit the disk immediately, but only that when they do hit the disk, they're not corrupt
/etc/mtab
Flushing on close is the wrong thing: it far exceeds the minimum requirements that most applications actually need, which will substantially reduce performance.
Face it: your side lost. "fsync everywhere" is an infeasible, untenable, and useless position to take.
fsync-on-rename creates a much better environment for application developers and users alike. The Right Thing happens by default, and I maintain that nobody actually wants the unsafe rename behavior. Allowing an application "choice" in this respect is a red herring.
The only improvement I'd make it to flush the file involves on every rename, not just renames that happen to overwrite an existing file. Under the current scheme, an application doing the write-close-rename to replace a file will still be put in a bind if the file to write doesn't exist yet. (i.e., you can still end up with a zero-length file where no such file ever existed on a running system)
A lot of scientists (and other people) seem to think just because it can be done, it should be done (and if they don't someone else will do it anyway).
Ain't the truth a pain? Sorry. Many people before you have proposed banning certain avenues of research, and science always wins.
"People of the same trade seldom meet together, even for merriment and diversion, but the conversation ends in a conspiracy against the public..." - Adam Smith
As an American, I'd be hesitant about traveling to the UK. You have insane libel laws, CCTV cameras everywhere, the RIP act, and so on. And don't get me started about Australia. It's pretty much the entire English-speaking world that's screwed up.
"Democrat" is a conservative frame. It's supposed to make the Democratic Party sound less appealing. Omitting the -ic marks you as someone who gets far too much of his information from conservative rags.
Article IV: The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.
...
Article IX: The enumeration in the Constitution, of certain rights, shall not be construed to deny or disparage others retained by the people.
Article X: The powers not delegated to the United States by the Constitution, nor prohibited by it to the States, are reserved to the States respectively, or to the people.
I know stare decisis distorts these clear sentences somewhat, but I think any impartial reader ought to conclude that arbitrary searches and detentions conducted without due cause are a violation of our natural rights, even when these searches and detentions are conducted in the course of travel.
And before you give me that "then don't fly" bullshit: Implied consent is simply a legalistic excuse for tyranny. Consent must always be explicitly given, or the word "content" is useless. "Implied content" is as much an oxymoron as "dry water".
IANAL, but my understanding is that refusal laws apply only after an arrest. Refusal to take a roadside breathalyzer does, however, constitute probably cause for arrest. Once you are placed under arrest as a result of either refusing or failing a roadside breathalyzer, you are given an evidentiary test, using with a more reliable machine. Refusing this test is what triggers the refusal laws.
Again, IANAL, but it seems better to always refuse a test if you know you're going to fail. Failure to blow is a civil penalty. A DUI is a criminal conviction that can haunt you for the rest of your life.
Based on a true story and submitted for your critical evaluation, dear reader, I present "America: A Dialogue".
Alice: I can't believe people want to bring the 9/11 terrorists into the US.
Bob: Well, it's the right thing to do. We need to stop torturing them and give them fair trials.
Alice: But not here. They're too dangerous to bring into the country.
Bob:: If our prisons can hold Timothy McVeigh, they can hold anyone. And they're being tortured over there.
Alice: McVeigh is one thing, but if we hold Al Qaeda terrorists, their supporters will come down through Canada and bail them out of Fort Leavenworth. I think they're just too dangerous to keep here, and an island is much more secure anyway.
Bob: But our soldiers are behaving like monsters and torturing these people.
Alice: They deserve it anyway. They attacked us on 9/11. And the real monsters are on top*. Don't criticize our troops who are just trying to do their job. It must hard dealing with those people.
Bob: We don't know they've done anything. They've never been tried. And our troops are responsible for what they do. Didn't we decide that at Nuremberg?
Alice: We know they attacked us. These things happen during war. They happen all the time. My friend's father told me of some nasty stuff that happened in Korea. This is no big deal.
Bob: [dramatic facepalm, exit stage left]
[Curtain drops, Alice appears from behind it]
Alice: I'm so glad we elected someone who can rehabilitate our image in the world.
[House lights]
* Note the slight improvement over the past few years
It is an excellent book, but I don't find the tax collapse scenario realistic. We already have a "non-traceable way for people to do transactions": it's called cash. Governments managed to collect taxes well before traceable transactions became the default.
If you torture the English language like that, I'd hate to see what you do to your poor code. Sloppy writing is a very good predictor of sloppy coding.
Now I can happily browse the web and I do sometimes click on text ads if they interest me and I happened to notice them.
Exactly! That's what people mean when they say that ad-blocking is democratic. They mean it literally: ad-blocking allows the public to participate in determining the proper balance between advertising and content. That's democracy in its most literal sense.
All ad-blocking does is give users the power to fight back against overzealous advertisers. It's not a given that ad-blocking software will be used to block all ads.
Look: you can add advertising to a given space until the incremental revenue from more advertising exceeds the consequent loss in eyeballs. Let's call that point P. Even without ad-blocking, there's a mechanism to prevent the web from becoming all advertising.
The problem is that P is obnoxious for most people, and it doesn't lead to an enjoyable experience. P is at Nash equilibrium, but it's not optimal from a utilitarian viewpoint (because many people are unhappy). In other words, the total benefit to society is less than it could be even though each of the players is playing as well as he can.
Now introduce ad-blocking to the mix. Users can now simply delete ads they find obnoxious. They will not go through the trouble of deleting ads that do not bother them however, and a new equilibrium point P1 is reached. Since people are happy with the ads at the P1 level, and because advertisers still see some revenue, I'd wager that P1 has a higher utilitarian value than P. (i.e., ad-blockers make the web a better place when you consider society as a whole.)
Because only the Administrators group can install software, and only the IT department is in the Administrators group
As a software developer, I'd demand quite a bit extra in salary if I had to deal with that bullshit. (Equivalently, I'd take a salary hit to be able to install and manage my own goddamn software, thank you very much.)
Ha ha. Ahahaha. HA HA HAHAHA HAHAHAH AAHAHA HA HA!
You can't be serious.
There's nothing magical about Flash. Free flash players already exist, and with sufficient demand, they'll mature even faster, and it's no harder in principle to block ads in a free flash player than in a free web browser.
There is no way to limit what the user can do with content you send him. Though that's a content-provider's dream, it ain't happening unless the entire PC software stack is locked down, and I don't see that happening.
Slashdot Mirror
Not one of these functions is guaranteed to exist by either C89 or C99. Don't comment on topics you don't understand.
Huh?
fcntl/lockf works fine over NFS so long as both sides are either using NFS4 or both sides are running NLM (the NFS locking daemon -- i.e. rpc.statd)
Dot-locking also works over NFS, though open(..., O_EXCL|O_CREAT) does not work, nor does flock. Have these worked on other systems, or started working under Linux?
Disturbingly enough, rename under OS X's HFS+ filesystem doesn't appear to be atomic even on a running system. If they can't get rename right on a running system, I'd hate to see what kind of scrambled mess the filesystem is after a crash.
Yes.
Precisely.
NO, NO, NO. write, fsync, close, rename is how you spell "atomically replace this file" in terms of system calls. It does precisely the correct thing on a running system. You yourself admit that it "used to work". It has worked for decades, in fact. (Though before journaling filesystems, all bets were off after a crash.)
That sequence of system calls is how applications tell the kernel to replace the given file. There is no useful interpretation of those system calls that doesn't involve an atomic replacement of the whole file. We don't need a separate system call: we already have the system calls. Nobody executing those system calls wants the dangerous interpretation of rename. At no time did an application developer sit down and think to himself, "I want to tell the kernel to perform an atomic rename, except when the system crashes. In that case, I want a zero-length file." Gods, no. Obviously, the application developer wanted to atomically replace the named file. Filesystems just need to honor the obvious intent of application developers.
Stop willfully misinterpreting me. The behavior is undefined as far as POSIX is concerned, not undefined in general. It's okay for programs to rely on behavior that goes beyond POSIX. A program that relied on POSIX and nothing else couldn't do anything about crash recovery anyway, since POSIX is silent on the topic of crashes.
There is nothing here to "fix". There is no "flaw".
As for a "good reason" --- programs don't depend on this behavior: users do. Users expect a good filesystem to maintain as many POSIX invariants as possible even after a crash. There is no purely POSIX way for a program to safeguard against a crash.
This is the operation salient to the ext4 discussion. The other operation is a distraction. (But for the record, POSIX also guarantees that they happen in order. How could it be otherwise?)
When XFS was first released, there was quite a buzz surrounding it before people realized they'd lose data. XFS, not ext3, would have been the the de-facto Linux standard had the developers not stubbornly refused to fix its dataloss bugs. By the time they finally got around to it (for some cases), there'd already been irreparable damage to XFS's reputation.
POSIX is a red herring here. It covers the behavior of a running system, and makes no guarantees about atomicity or durability following a crash. After a crash and as far as POSIX goes, it's perfectly legitimate to overwrite the entire disk with hentai. Every crash recovery technique goes beyond POSIX because POSIX says nothing about crashes.
It most certainly does! On a running system, if you rename B over A, at no point does any process on the system observe a file called "A" that does not have either the contents of the old A or the contents of B. THIS ATOMICITY IS A FUNDAMENTAL POSIX GUARANTEE.
Filesystems should do their best to honor this guarantee (which always applies on a running system, remember) even when the system crashes. Filesystems don't have to do that according to POSIX. Instead, they should do it because it's a sane thing to do, and doesn't violate anything POSIX guarantees. POSIX is not the arbiter of what a good system should be. It's perfectly reasonable to make guarantees that go beyond POSIX, and every real-world operating system does precisely that. POSIX guarantees are necessary but insufficient for a reasonable system in 2009.
This statement is incorrect. Suppose you want to atomically replace the contents of file "foo". Your application will write a file "foo.tmp", then call rename("foo.tmp", "foo"). At no time on a running system does any process observe a file called "foo" that does not have either the new or the old contents, and this invariant holds true whether or not "foo", "foo.tmp", or any other file has been flushed to the disk.
On the filesystem level, the kernel can actually write the contents of foo.tmp to disk whenever is convenient. The only constraint is that the on-disk name record for "foo" must be updated to point to the new data blocks from foo.tmp only after these data blocks have themselves been written to disk. That's the issue here: without that ordering guarantee, the kernel can write a file's name record before its data blocks. If the system crashes after the name record is written but before the data blocks are, what's observed on the recovered system is a zero-length file.
That's the problem here: the kernel is conjuring out of thin air a zero-length file that never actually existed on a running system.
Forcing applications to call fsync is not only an onerous burden on application developers, but it also reduces performance because it gives the filesystem less freedom than the much looser constraint on rename above.
Flushing on close is the wrong thing: it far exceeds the minimum requirements that most applications actually need, which will substantially reduce performance.
Face it: your side lost. "fsync everywhere" is an infeasible, untenable, and useless position to take.
fsync-on-rename creates a much better environment for application developers and users alike. The Right Thing happens by default, and I maintain that nobody actually wants the unsafe rename behavior. Allowing an application "choice" in this respect is a red herring.
The only improvement I'd make it to flush the file involves on every rename, not just renames that happen to overwrite an existing file. Under the current scheme, an application doing the write-close-rename to replace a file will still be put in a bind if the file to write doesn't exist yet. (i.e., you can still end up with a zero-length file where no such file ever existed on a running system)
Ain't the truth a pain? Sorry. Many people before you have proposed banning certain avenues of research, and science always wins.
Err, yes:
"People of the same trade seldom meet together, even for merriment and diversion, but the conversation ends in a conspiracy against the public..." - Adam Smith
As an American, I'd be hesitant about traveling to the UK. You have insane libel laws, CCTV cameras everywhere, the RIP act, and so on. And don't get me started about Australia. It's pretty much the entire English-speaking world that's screwed up.
It's not "Democrat". It's "Democratic".
"Democrat" is a conservative frame. It's supposed to make the Democratic Party sound less appealing. Omitting the -ic marks you as someone who gets far too much of his information from conservative rags.
Reagan had it wrong. The most chilling statement in the world is not "I'm from the government, and I'm here to help", but "Papers, please."
It says it quite clearly here:
I know stare decisis distorts these clear sentences somewhat, but I think any impartial reader ought to conclude that arbitrary searches and detentions conducted without due cause are a violation of our natural rights, even when these searches and detentions are conducted in the course of travel.
And before you give me that "then don't fly" bullshit: Implied consent is simply a legalistic excuse for tyranny. Consent must always be explicitly given, or the word "content" is useless. "Implied content" is as much an oxymoron as "dry water".
IANAL, but my understanding is that refusal laws apply only after an arrest. Refusal to take a roadside breathalyzer does, however, constitute probably cause for arrest. Once you are placed under arrest as a result of either refusing or failing a roadside breathalyzer, you are given an evidentiary test, using with a more reliable machine. Refusing this test is what triggers the refusal laws.
Again, IANAL, but it seems better to always refuse a test if you know you're going to fail. Failure to blow is a civil penalty. A DUI is a criminal conviction that can haunt you for the rest of your life.
Based on a true story and submitted for your critical evaluation, dear reader, I present "America: A Dialogue".
Alice: I can't believe people want to bring the 9/11 terrorists into the US.
Bob: Well, it's the right thing to do. We need to stop torturing them and give them fair trials.
Alice: But not here. They're too dangerous to bring into the country.
Bob:: If our prisons can hold Timothy McVeigh, they can hold anyone. And they're being tortured over there.
Alice: McVeigh is one thing, but if we hold Al Qaeda terrorists, their supporters will come down through Canada and bail them out of Fort Leavenworth. I think they're just too dangerous to keep here, and an island is much more secure anyway.
Bob: But our soldiers are behaving like monsters and torturing these people.
Alice: They deserve it anyway. They attacked us on 9/11. And the real monsters are on top*. Don't criticize our troops who are just trying to do their job. It must hard dealing with those people.
Bob: We don't know they've done anything. They've never been tried. And our troops are responsible for what they do. Didn't we decide that at Nuremberg?
Alice: We know they attacked us. These things happen during war. They happen all the time. My friend's father told me of some nasty stuff that happened in Korea. This is no big deal.
Bob: [dramatic facepalm, exit stage left]
[Curtain drops, Alice appears from behind it]
Alice: I'm so glad we elected someone who can rehabilitate our image in the world.
[House lights]
* Note the slight improvement over the past few years
Did you read my post you ridiculous, authority-kowtowing simpleton?
It is an excellent book, but I don't find the tax collapse scenario realistic. We already have a "non-traceable way for people to do transactions": it's called cash. Governments managed to collect taxes well before traceable transactions became the default.
If you torture the English language like that, I'd hate to see what you do to your poor code. Sloppy writing is a very good predictor of sloppy coding.
Exactly! That's what people mean when they say that ad-blocking is democratic. They mean it literally: ad-blocking allows the public to participate in determining the proper balance between advertising and content. That's democracy in its most literal sense.
All ad-blocking does is give users the power to fight back against overzealous advertisers. It's not a given that ad-blocking software will be used to block all ads.
Look: you can add advertising to a given space until the incremental revenue from more advertising exceeds the consequent loss in eyeballs. Let's call that point P. Even without ad-blocking, there's a mechanism to prevent the web from becoming all advertising.
The problem is that P is obnoxious for most people, and it doesn't lead to an enjoyable experience. P is at Nash equilibrium, but it's not optimal from a utilitarian viewpoint (because many people are unhappy). In other words, the total benefit to society is less than it could be even though each of the players is playing as well as he can.
Now introduce ad-blocking to the mix. Users can now simply delete ads they find obnoxious. They will not go through the trouble of deleting ads that do not bother them however, and a new equilibrium point P1 is reached. Since people are happy with the ads at the P1 level, and because advertisers still see some revenue, I'd wager that P1 has a higher utilitarian value than P. (i.e., ad-blockers make the web a better place when you consider society as a whole.)
As a software developer, I'd demand quite a bit extra in salary if I had to deal with that bullshit. (Equivalently, I'd take a salary hit to be able to install and manage my own goddamn software, thank you very much.)
Ha ha. Ahahaha. HA HA HAHAHA HAHAHAH AAHAHA HA HA!
You can't be serious.
There's nothing magical about Flash. Free flash players already exist, and with sufficient demand, they'll mature even faster, and it's no harder in principle to block ads in a free flash player than in a free web browser.
There is no way to limit what the user can do with content you send him. Though that's a content-provider's dream, it ain't happening unless the entire PC software stack is locked down, and I don't see that happening.