On 03/08/2014 05:48, NeilBrown wrote:

You are very unlikely to see UREs just be reading the drive over and over a
again.  You easily do that for years and not get an error.  Or maybe you got
one just then.

True. I read over 40 TB from this disk and I haven't find any error. 
Some SMART attribute reported so far:
ID  NAME                    FLAG     V     W     T      R
197 Current_Pending_Sector  0x0012   100   100   000    0
198 Offline_Uncorrectable   0x0010   100   100   000    0

As you can find, no error was reported, and I don't find anything 
suspicious in dmesg. At least, this should prove that article as this 
[1] are quite wrong.

Maybe URE errors are related to unsuccessful writes in the first place. 
I will try to repeat the test intermixing read with full-disk writes.


[1] 
http://subnetmask255x4.wordpress.com/2008/10/28/sata-unrecoverable-errors-and-how-that-impacts-raid/

If you want to see how the system responds when it hits a URE, you can use the
hdparm command and the "--make-bad-sector" option.  There is also a
"--repair-sector" option which will (hopefully) repair the sector when you
are done.

NeilBrown

quoted

Thanks.

Il 2014-07-31 09:16 Gionatan Danti ha scritto:

quoted

quoted

Yes, you can usually get your data back with mdadm.

With latest code, a URE during recovery will cause a bad-block to be
recorded
on the recovered device, and recovery will continue.  You end up with
a
working array that has a few unreadable blocks on it.

NeilBrown

This is very good news :)
I case of parity RAID I assume the entire stripe is marked as bad, but
with mirror (eg: RAID10) only a single block (often 512B) is marked
bad on the recovered device, right?

 From what mdadm/kernel version the new behavior is implemented? Maybe
the software RAID on my CentOS 6.5 is stronger then expected ;)

Regards.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8