Re: 12x performance drop on md/linux+sw raid1 due to barriers [xfs]

[Eric Sandeen <sandeen@sandeen.net>]

Ralf Liebenow wrote:
> Hello !
> 
>> Correct ordering can be proven to be enough to provide transactional
>> correctness, enough to ensure that filesystems can not get corrupted
>> on power down.
> 
> Please beware that caching RAID controllers which are not battery
> backed and the harddisk (when write caching) may decide to 
> re-order writes to the disk, so the ordering imposed by the 
> operating system (filesystem driver) may not be retained. 
> This is usually done by harddisks and
> controllers to minimize seek times and thats what disk
> command queueing is good for. So ordering can only be retained
> if all external caching mechanism and command queueing are
> switched off. 

That's not necessarily true.

The only *requirement* for barriers is preservation of ordering.  It is
*implemented* today by cache flushing, because that's the best we can do
for now (as I understand it).

It is certainly possible that an IO could be flagged which tells the
drive that it may not rearrange the cache destaging across a barrier IO.
 It could cache at will, as long as the critical ordering is maintained.

http://www.t13.org/Documents/UploadedDocuments/docs2007/e07174r0-Write_Barrier_Command_Proposal.doc

So even though barriers are be implemented w/ cache flushes today, it
would be a mistake to rely on that implementation.  IOW, don't confuse
cache flushing w/ ordering requirements just because the ordering
problem is solved *today* with cache flushes.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs