On Wed, Jul 04, 2012 at 10:36:40AM +0400, Michael Tokarev wrote: > > 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 for your clarification. :-) Turning FUA on can reduce the overhead of flushes AFAIK. In our product system we have a lot of SATA disks with FUA, but we must add a boot parameter 'libata.fua=1' to enable it. Meanwhile there already has a number of SATA disks that have supported this feature. So I think maybe we can enable it. Regards, Zheng -- 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
