On 07/29/2010 03:59 PM, James Bottomley wrote:
On Thu, 2010-07-29 at 15:56 -0400, Ric Wheeler wrote:
On 07/29/2010 03:49 PM, Christoph Hellwig wrote:
On Thu, Jul 29, 2010 at 03:44:31PM -0400, Ric Wheeler wrote:
I confess that I am a bit fuzzy on FUA, but think that it means that any
FUA tagged IO will go down to persistent store before returning.
Exactly.
If so, then all order dependent IO would need to be issued in order and
tagged with FUA. It would not suffice to tag just the commit record as
FUA, or do I misunderstand what FUA does?
The commit record is ext3/4 specific terminalogy. In xfs we just have
one type of log buffers, and we could tag that as FUA. There is very
little other depenent I/O, but if that is present we need a pre-flush
for it anyway.
I assume that for ext3 it would get more complicated depending on the
journal mode. In ordered or data journal mode, we would have to write
the dependent non-journal data tagged with FUA, then the FUA tagged
transaction and finally the FUA tagged commit block.
Not sure how FUA performs, but writing lots of small tagged writes is
probably not good for performance...
That's basically everything FUA ... you might just as well switch your
cache to write through and have done.
I think that for data ordered mode that is all of the data more or less
would get tagged. For data journal, would we have to send 2x the write
workload down with tags? I agree that this would be dubious at best.
Note that using the non-FUA cache flush commands, while brute force,
does have a clear win on slower devices (S-ATA specifically). Each time
I have looked, using the write cache enabled on S-ATA was a win (big win
on streaming write performance, not sure why).
On SAS drives, the flush barriers were not as large a delta (do not
remember which won out).
This, by the way, is one area I'm hoping to have researched on SCSI
(where most devices do obey the caching directives). Actually see if
write through without flush barriers is faster than writeback with flush
barriers. I really suspect it is.
James
There are clearly much better ways to do this. Even the flushes, if we
could flush ranges that matched the partition under the file system,
would be better than today where we flush the entire physical device.
Ric
--
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
