On Wed, Jul 28, 2010 at 11:24:11AM +0200, Tejun Heo wrote: > On 07/28/2010 11:16 AM, Christoph Hellwig wrote: > > The problem is to emulate it properly on devices that do no actually > > support the FUA bit. Of which we unfortunately have a lot given > > that libata by default disables the FUA support even if the device > > supports. > > These were the reasons. > > * Some controllers puke for FUA commands whether the device supports > it or not. > > * Low confidence in drives reporting FUA support. New features in ATA > world seldomly work well and I'm fairly sure there are devices which > report FUA support and handle FUA writes exactly the same way as > regular writes. :-( Jens recently told that Windows seems to send lots of FUA requests these days, which should really have helped shacking it out. > completely, it might make sense to revisit it. But, in general, I > think most barriers, even when relaxed, would at least involve single > flush before the FUA write and in that case I'm pretty skeptical how > useful FUA write for the barrier itself would be. At least for XFS we should be able to get away with almost no full flush at all for special workloads (no fsyncs/syncs, not appending file writes). With more normal workloads that get a fsync/sync once in a while we'd almost alwasy do a full flush for every log write, though. -- 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
