| |||||||||||||
|
| |||||||||||||
Re: Making write barriers actually workRe: Making write barriers actually workPosted Oct 16, 2003 11:02 UTC (Thu) by daniel (subscriber, #3181)In reply to: Re: Making write barriers actually work by axboe Parent article: Making write barriers actually work "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 :-)
(Log in to post comments)
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)) { Neither QUEUE_ORDERED_TAG or QUEUE_ORDERED_FLUSH are ever set in mainline. 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.
|
|
||||||||||||