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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4FF3E478.50609@msgid.tls.msk.ru>
Date:	Wed, 04 Jul 2012 10:36:40 +0400
From:	Michael Tokarev <mjt@....msk.ru>
To:	Jeff Garzik <jeff@...zik.org>, linux-kernel@...r.kernel.org,
	linux-ide@...r.kernel.org, linux-scsi@...r.kernel.org,
	Zheng Liu <wenqing.lz@...bao.com>
Subject: Re: [RFC][PATCH] libata: enable SATA disk fua detection on default

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/