drive selection for disk arrays

[Karl Denninger]

On 3/27/2020 20:46, David Christensen wrote:
> On 2020-03-27 17:45, Karl Denninger wrote:
>>
>> On 3/27/2020 19:39, David Christensen wrote:
>>> On 2020-03-27 02:45, Polytropon wrote:
>>>
>>>> When a drive _reports_ bad sectors, at least in the past
>>>> it was an indication that it already _has_ lots of them.
>>>> The drive's firmware will remap bad sectors to spare
>>>> sectors, so "no error" so far.
>>>
>>> If a drive detects an error, my guess is that it will report the error
>>> to the OS; regardless of the outcome of a particular I/O operation
>>> (data read, data written, data lost) or internal actions taken (block
>>> marked bad, block remapped, etc.).  It is then up to the OS to decide
>>> what to do next.  RAID and/or ZFS offer the means for shielding the
>>> application from I/O and drive failures.
>>>
>> Yes, but...
>>
>> Those drives that can do "SMART" will report (if you have a patrol
>> daemon for it running) if they do a "silent" sector reassignment.
>> Otherwise the OS is none the wiser and neither is ZFS (or anything
>> else.)  
>
> I guess I need to RTFM:
>
> https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/serial-ata-ahci-spec-rev1-3-1.pdf
>
>
>
>> Needless to say if reassignments increase you might want to
>> think about swapping the drive *before* it blows up!
>
> Agreed.
>
>
>> I have the daemon running on all my machines.  It works nicely and has
>> warned me a few times over the years.  With that said it doesn't ALWAYS
>> catch a drive before it pukes.
>
> Are  you referring to periodic, smartd, or something else?
>
>
Smartd.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20200327/622abec1/attachment.bin>