David Masover wrote:
Christopher Chan wrote:
Anyway I guess you are smarter than Hans then since you obviously
feel that his use of fsync is a bit of unneeded integrity.
I'm not going to respond to this until you phrase it in a way which
doesn't gossip about Hans. Unless something has changed, Hans is still
unable to communicate on this list, so it's entirely unfair for either
of us to put words in his mouth as long as he isn't here to defend himself.
Look, the reason why reiser4 uses fsync is to guarantee data and
filesystem integrity which from what I have heard is far better than
that of ext3 which is at the moment the leader in this regard.
Anyway, this rant went on longer than I wanted it to, but since I've
brought it down to a question of economics, I don't really know the
answer. I do think, however, that arguing always for or against fsync
is absolutist and ultimately wrong.
Obviously we should take this question of fsync to its creator and all
those who use it since they are all crippling their software
implementing this dreadful useless function and actually making use of it.
I'm sorry, did I say it was useless? And I quote:
"arguing always for OR AGAINST fsync is absolutist and ultimately wrong."
I'm not saying fsync is always the wrong choice, either. I'm simply
saying it isn't always the right one.
When ANY piece of software be it a database, mta or a filesystem wants
to know that what was written is safe on disk, it uses fsync, end of
story. NO filesystem worth its salt will not not use fsync or fsyncdata
when its come to the part of wanting a guarantee that data/metadata has
been written to disk.
And no, I'm not impressed by what the majority thinks. On a larger
scale, the majority thinks Windows is their only real option, and that
computers are inherently unstable and insecure, and that software
engineers will never listen to them and always make it their fault.
The majority really have no choice. Most of the software they need are
on Windows. If Linux had come out earlier or GNU had a viable working
solution earlier or they had got more exposure, Unix might have been the
dominant desktop OS instead of DOS/Windows/M$. I do not believe the
majority chose to think Windows is their only real option. You can put
in something else and they will happily use it until they find out they
cannot use 'necessary software that runs on Windows only' and then they
switch back. If you look at how Apple has been rather successful with
their desktops/laptops you can see that some people are prepared to dump
Windows for what it is, a piece of unstable and insecure crap.
Open source too has to share part of the blame when it comes to the desktop.
If you're going to debate this, please try to debate it with just you
and me. You shouldn't need to invoke Hans-who-isn't-here, or every
software engineer in the past 20 years. If your point is really that
solid, it should stand on its own, without you having to intimidate me
about how stupid I am for questioning established practices.
If you had brought up a solid point against fsync instead of completely
irrelevant comparisons and sticking to your faulty points then I won't
have bothered pointing out that you are being stupid for questioning
established practices without grounds.
I'd rather drop the debate, because, as I said, we mostly agree.
I am not sure we do. Until you drop the fsync is unnecessary for data
integrity part, we don't.
How could I ever forget that banks use unreliable media?
So how do they deal with that issue? (Or are you being sarcastic?)
Obviously, fsync won't save them, so how do they deal with it?
Come on, David, stop acting like some ignorant admin. Media problems are
migitated by having redundant failovers available.
I won't speculate on Hans' opinions on whether fsync is really a good
design decision -- at least, not without him able to respond.
You don't have to. He did not create fsync and so you don't have to
worry about whether fsync is a good design decision.
He could have as easily removed it, the way I patched it out. Pretended
to implement it, but simply have a stub that always returns success.
Heh. Did you know that there was a time that Linux pretended to sync
when it did not actually do it? The result? fsck, fsck, fsck
He certainly has opinions about whether fsync is a good idea, why he
wants reiser4 to have better fsync performance, and many other things
that we should not discuss in his absence.
The only way you can get better fsync performance is to use RAID under
the filesystem or do full journaling on a NVRAM block device. Get this
through your head. fsync is not written/created by Hans. fsync was
already part of the Unix 98, Unix 95, 4.3BSD and SVID 3 APIs. (see
http://www.unix.org/apis/1.r.html) I doubt very much that Hans has any
opinions whatsoever on a standard API call. So you can stop the Hans is
not here nonsense.
Until Hans is back on the list, any email which says anything about
Hans' opinions or intelligence is no better than teenage gossip. Please,
stop acting like a high-school girl.
Ooh, where did I say anything about Hans' opinions or intelligence?
