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

[Zheng Liu <gnehzuil.liu@xxxxxxxxx>]

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