On Wed, Mar 02, 2011 at 10:30:57AM +0300, Michael Tokarev wrote: > > I believe the way the block layer uses it, basically it only saves the > > overhead of one transaction to the drive. It might be significant on > > some workloads (especially on high IOPS drives like SSDs) but it's > > likely not a huge deal. > > One transaction per what? If it means extra, especially "large" > transaction (lile flush with a wait) per each fsync-like call, > that can be huge deal actually, especially on database-like > workloads (lots of small syncronous random writes). The way flushes are used by filesystems is that FUA is usually only used right after another FLUSH. ie. Using FUA replaces FLUSH + commit block write + FLUSH sequence to FLUSH + FUA commit block write. Due to the preceding FLUSH, the cache is already empty, so the only difference between WRITE + FLUSH and FUA WRITE becomes the extra command issue overhead which is usually almost unnoticeable compared to the actual IO. Another thing is that with the recent updates to block FLUSH handling, using FUA might even be less efficient. The new implementation aggressively merges those commit writes and flushes. IOW, depending on timing, multiple consecutive commit writes can be merged as, FLUSH + commit writes + FLUSH or FLUSH + some commit writes + FLUSH + other commit writes + FLUSH and so on, These merges will happen with fsync heavy workloads where FLUSH performance actually matters and, in these scenarios, FUA writes is less effective because it puts extra ordering restrictions on each FUA write. ie. With surrounding FLUSHes, the drive is free to reorder commit writes to maximize performance, with FUA, the disk has to jump around all over the place to execute each command in the exact issue order. I personally think FUA is a misfeature. It's a microoptimization with shallow benefits even when used properly while putting much heavier restriction on actual IO order, which usually is the slow part. That said, if someone can show FUA actually brings noticeable performance benefits, sure, let's do it, but till then, I think it would be best to leave it up in the attic. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
