Re: [RFC][PATCH] libata: enable SATA disk fua detection on default

[Michael Tokarev <mjt@tls.msk.ru>]

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