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

Re: Making write barriers actually work

Posted Oct 16, 2003 9:41 UTC (Thu) by axboe (✭ supporter ✭, #904)
In reply to: Making write barriers actually work by daniel
Parent article: Making write barriers actually work

Hmm odd, I consider it mainly a data integrity patch. There are no performance gains in the version I sent out, but it sure is a lot safer. The fact that you can get performance gains as well is just an extra future bonus.

(Log in to post comments)

Re: Making write barriers actually work

Posted Oct 16, 2003 11:02 UTC (Thu) by daniel (subscriber, #3181) [Link]

"I consider it mainly a data integrity patch."

For correctness it is only essential that barrier requests are properly failed for devices that do not support them and that queues properly indicate that barriers are not supported.

We've gotten this far without barriers, we could possibly manage to wait for 2.6.1 :-)

Re: Making write barriers actually work

Posted Oct 17, 2003 10:21 UTC (Fri) by axboe (✭ supporter ✭, #904) [Link]

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.

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.