Mike Snitzer wrote: > On Thu, Aug 26 2010 at 6:50pm -0400, > Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > > > Once we have a need for using request-based DM for something other than > > multipath we can take a fresh look at implementing rq-based FLUSH+FUA. > > > > Mike > > > > p.s. I know how hard NEC worked on request-based DM's barrier support; > > so I'm not suggesting this lightly. For me it just seems like we're > > carrying complexity in DM that hasn't ever been required. > > To be clear: the piece that I was saying wasn't required is the need to > for request-based DM to clone a FLUSH to send to multiple targets > (saying as much was just a confusing distraction.. please ignore that). > > Anyway, my previous email's question still stands. On a slightly related note: DM suggests a reason for the lower layer, or the request queues, to implement the trivial optimisation of discarding FLUSHes if there's been no WRITE since the previous FLUSH. That was mentioned elsewhere in this big thread as not being worth even the small effort - because the filesystem is able to make good decisions anyway. But once you have something like RAID or striping, it's quite common for the filesystem to issue a FLUSH when only a subset of the target devices have received WRITEs through the RAID/striping layer since they last received a FLUSH. -- Jamie -- 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
