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. * With the traditional strong barriers, it doesn't make much difference whether FUA is used or not. The full queue has already been stalled and flushed by the time barrier write is issued and all that we save is overhead for a single command which doesn't make any difference to actual timing of completion. * 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. :-( So, until now, it just wasn't worth the effort / risk. If filesystems can make use of more relaxed ordering including avoiding full flush 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. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
