Which is why data important software use fsync/fsyncdata to minimize data loss from crashes.

If (and only if) you actually read and accepted the paragraph you're quoting there, the point is that using fsync and fdatasync on these is kind of like doing bad block relocation in software, when the hard disk is already doing it for you. There are situations where it's useful, but mostly, it's just a performance drain without a point.

You have no idea what fsync/fsyncdata does. They cannot be compared to bad block relocation at all. That is an apples to oranges comparison.


I don't necessarily agree with this point of view, but there you go.

could probably argue the other side just as effectively. Besides, at
least on my experimental/gaming rig, I like a little adrenaline in my
admin work!


Try arguing why you lost thousands of mails when the box crashed and justifying it.

There aren't thousands of mails on my experimental dev/gaming rig. Also, it hasn't crashed in a month or two (I seem to have upgraded/hacked my way out of its last major crasher), and it's running all kinds of experimental stuff. Sure, individual programs crash from time to time (especially my hacks), but that's irrelevant to the fsync discussion.

I was not referring to your gaming rig. Did you say that you don't use fsync for your production boxes?

So, as far as I can tell, this mailserver (that I'm sending this from right now), which is amd64/reiser4/no_fsync, hasn't lost a single message. And I don't even have an APM on it (although that reminds me, I need to buy one now, as in, "tomorrow" now.)

Heh. Just wait till you get a crash shortly after a write with fsync disabled.


Anyway, are we done here? I don't think I disagree with your points, maybe just your absolutism.

Ha! Got tell that to a bank or any body who uses a database to store important data. Hans knows what he is doing providing data guarantee with fsync. I was very surprised when I heard all those reports about zero data loss on reiser4 boxes after a crash. Now I have an idea why.

Reply via email to