Re: Which version will be merged into mainline kernel?

[Christopher Chan <chrisfz@netvigator.com>]

> So, you have to have a way to insure data integrity beyond flushing it 
> to disk. Flushing it to disk is just a bit of unneeded integrity, that 
> costs a little bit of performance, and would probably save your ass in 
> one or two edge cases, but those cases shouldn't normally happen, and if 
> you're properly prepared for the hardware failing, you're properly 
> prepared for those edge cases, also.

fsync costs a lot of performance. Disk I/O is orders of magnitude off 
RAM. Anyway I guess you are smarter than Hans then since you obviously 
feel that his use of fsync is a bit of unneeded integrity.

> 
> 
> 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.

> 
> 
>>> 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.
> 
> Yes, he's providing warm fuzzies for the banks. What are the banks doing 
> about hard disk failure? Remember, fsync only guarantees the data was 
> successfully written to a physical media -- it doesn't guarantee the 
> data will still be there when you want to go read it.

How could I ever forget that banks use unreliable media?

> 
> 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.