On 04.07.2012 06:47, Zheng Liu wrote: [] >> I guess it can be enabled after LOTS of testing of various drives out >> there, which shows that no current drives have issues with FUA anymore, >> and after building a black-list of devices which misbehave. It is quite >> a big project, I think. But what it gives us in return? >> >> (I've no idea if this is the right answer, speaking of myself only) > > Thanks for the reply. Indeed it is quite a big project but we enable > FUA feature for SAS disk. Is there any differences? Yes, there's a very big difference with SAS disks. Even in parallel SCSI world DPO/FUA has been enabled since the day it has been implemented IIRC, because, apparently, hardware raid controllers enabled it too. In other words, it has been tested and proved to be working even before linux implementation. When first SAS disks started appearing, DPO/FUA were enabled for them in linux already -- at that time any breakage were solely due to the particular disk model, and were easy to blacklist, if necessary, since only a few disk models were in production. With SATA disks, initial hardware implementation proved to be more non-functional than functional, ie, initially there were more drives with non-working FUA. I have a few not-so-old SATA drives here which behaves strangely when FUA is enabled (I don't remember exact details, but I had to disable FA again after I tried to enable it once, the system started behaving not as good as before). So, for SATA drives, we've exactly the opposite picture: we've some proof that "generally, drives dislikes FUA", and now when fua has been disabled for a lot of drives and users, turning it on by default needs lots of testing. But I ask again: what is the benefit of turning FUA on to start with? Thanks, /mjt -- 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
