Re: libata FUA revisited

[Jeff Garzik <jeff@garzik.org>]

Tejun Heo wrote:
> Hello,
>
> Robert Hancock wrote:
> [--correct summary snipped--]
> > Given the above, what I'm proposing to do is:
> >
> > -Remove the blacklisting of Maxtor BANC1G10 firmware for FUA. If we 
> > need to FUA-blacklist any drives this should likely be added to the 
> > existing "horkage" mechanism we now have. However, at this point I 
> > don't think that's needed, considering that I've seen no conclusive 
> > evidence that any drive has ever been established to have broken FUA.
>
> Agreed.
>
> > -Add a new port flag ATA_FLAG_NO_FUA to indicate that a controller 
> > can't handle FUA commands, and add that flag to sata_sil. Force FUA 
> > off on any drive connected to a controller with this bit set.
> >
> > There was some talk that sata_mv might have this problem, but I 
> > believe the conclusion was that it didn't. The only controllers that 
> > would are ones that actually try to interpret the ATA command codes 
> > and don't know about WRITE DMA FUA.
>
> I think it would be better to add ATA_FLAG_FUA instead of ATA_FLAG_NO_FUA.

This is an interesting (if small) problem.  I would propose a third 
option:  add ATA_FLAG_NO_FUA to applicable /SATA/ drivers, but leave 
those without ATA_FLAG_SATA alone.

	Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/