On 12/03/13 00:38, James Bottomley wrote: > Well this would be because we don't guarantee order at any granularity > below barriers. We won't reorder across barriers but below them we can > reorder the commands and, of course, we use simple tags for queuing > which entitles the underlying storage hardware to reorder within its > internal queue. Previously, when everything was single threaded issue, > you mostly got FIFO behaviour because reorder really only occurred on > error or busy, but I would imagine that's changing now with multiqueue. Reordering SCSI commands was fine as long as hard disks were the only supported storage medium. This is because most hard disk controllers do not perform writes in the order these writes are submitted to their controller. However, with several SSD models it is possible to tell the controller to preserve write order. Furthermore, the optimizations that are possible by using atomic writes are only safe if it is guaranteed that none of the layers between the application and the SCSI target changes the order in which an application submitted these atomic writes. In other words, although it was safe in the past to reorder the writes submitted between two successive barriers such reordering would eliminate several of the benefits of atomic writes. A quote from the draft SCSI atomics specification (http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-064r7.pdf): <quote> Atomic writes may: a) increase write endurance A) reducing writes increases the life of a flash-based SSD b) increase performance A) reducing writes results in fewer system calls, fewer I/Os over the SCSI transport protocol, and fewer interrupts c) improve reliability for non-journaled data d) simplify applications A) reduce or eliminate journaling B) keep applications from managing atomicity </quote> Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
