| |||||||||||||
|
| |||||||||||||
Yup. It's the beginning of the end.Yup. It's the beginning of the end.Posted Apr 1, 2009 7:54 UTC (Wed) by khim (subscriber, #9252)In reply to: The end of LWN comment dialog? by bojan Parent article: That massive filesystem thread
If you read my original post in this thread, you will find that I am pointing at inconsistencies of what Linus describes as reality check. Nope. You are being 100% smart-ass. Linus's reality check is not inconsistent. It's description of reality and reality is not consistent. Whenever it was? You have different factors and in different but quite real situations different factors prevail. So, I ridicule (among other things) his conclusion that: ext3 sucks at doing fsync(), hence we should drop fsync(). That's different facet of reality. When you consider reality from kernel developer POV what the applications are doing is your "unchangeable fact", your "speed of light", when you consider reality from application developer POV what the kernel does is "unchangeable fact" and you should deal with it. This is true even if kernel developer and application developer is the same person. You can only think differently if your application is designed to only be used "in-house" and you can always guarantee control over both kernel and userspace - and git was not designed to only be used "in-house"... And, I do not see how I am not being polite by exercising criticism with a hint of sarcasm. You are exercising ignorance with a hint of sarcasm. That's different.
(Log in to post comments)
Yup. It's the beginning of the end. Posted Apr 1, 2009 8:29 UTC (Wed) by bojan (subscriber, #14302) [Link]
> When you consider reality from kernel developer POV what the applications are doing is your "unchangeable fact", your "speed of light", when you consider reality from application developer POV what the kernel does is "unchangeable fact" and you should deal with it.
Let me review.
When another Unix kernel (or Linux) holds your data in buffers and commits metadata only (because it is allowed to), you, as an application developer, deal with it by ignoring that fact.
And, when your file system does crazy things with the perfectly good system call, you also ignore it as a kernel developer.
WOW, is that now the new "very special relativity"? We pick whichever behaviour is the most narrow to a specific file system and go with that?
Yup. It's the beginning of the end. Posted Apr 1, 2009 14:22 UTC (Wed) by drag (subscriber, #31333) [Link]
> When another Unix kernel (or Linux) holds your data in buffers and commits metadata only (because it is allowed to), you, as an application developer, deal with it by ignoring that fact.
POSIX allows you never to write data to disk at all. That will make your file system very fast. After all you can have a POSIX-compliant file system that operates off of ramdisk quite easily.
POSIX file system access is designed to describe the interface layer between userland and the file system. It leaves the actual integration between the file system and the hardware, as well as the internals to the file system itself is left up to the developer of the OS.
It is like if you discovered all of a sudden a network service provided by a Apache-based web app uses SSL badly so that all usernames and passwords are transmitted over the Web in plain text... then you complain about it and the developer says back to you that his application's behavior is allowed by TCP/HTTP/SSL and that you should be changing your password with each usage, like people who use his app correctly do. Then he emails you some documentation from a security expert that says you should change your password frequently and that many other protocols like telnet or ftp send your username and password over the network in plain text.
Yup. It's the beginning of the end. Posted Apr 1, 2009 16:10 UTC (Wed) by foom (subscriber, #14868) [Link]
This is starting to get very repetitive...all these points have been made already at least once in one
of the other article's threads. I'd like to suggest that it might be in everyone's interest to move on to more useful pass-times than rehashing the same arguments over and over again every time there's an update on the subject.
|
|
||||||||||||