Re: libata FUA revisited

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux