Re: Making write barriers actually work [LWN.net]

Re: Making write barriers actually work

Posted Oct 17, 2003 10:21 UTC (Fri) by axboe (✭ supporter ✭, #904)
In reply to: Re: Making write barriers actually work by daniel
Parent article: Making write barriers actually work

For correctness, it's is essential that data is on disk when the fs thinks it is. And right now it isn't. I think the problem is bigger than you think. Just be glad your power supply is stable :-)

But please use your 'we' carefully, say 'I' if you are just referring to yourself. At least SuSE and EMC cares enough about customer data integrity to have been using the patches for a long time on the 2.4 base.

(Log in to post comments)

Re: Making write barriers actually work

Posted Oct 20, 2003 13:32 UTC (Mon) by daniel (subscriber, #3181) [Link]

"But please use your 'we' carefully, say 'I' if you are just referring to yourself. At least SuSE and EMC cares enough about customer data integrity to have been using the patches for a long time on the 2.4 base."

But you are still mixing up performance with integrity. For integrity you only need these four lines:

+ if (barrier && (q->ordered == QUEUE_ORDERED_NONE)) {
+ err = -EOPNOTSUPP;
+ goto end_io;
+ }

Neither QUEUE_ORDERED_TAG or QUEUE_ORDERED_FLUSH are ever set in mainline.
Of course we always like more performance and more kernel tweaking, however there are good reasons to respect the rules of a freeze.

And I'll stick with the "we" thanks. Vendors are perfectly happy to continue to distinguish their offerings by carrying performance patches, whereas the rest of us are probably more interested in an orderly march to 2.6.0.