Le ven. 21 déc. 2018 à 01:45, Wols Lists <antlists@xxxxxxxxxxxxxxx> a écrit : > By changing the timeout on the WD to 180, you have just told the kernel > to wait for up to three minutes if the WD has a problem. That is > probably going to cause users of the computer a lot of grief should such > a problem occur. > > Is the Seagate faulty? The official spec says that you should EXPECT one > problem every ten terabytes. I don't know how much usage this drive has > had, and in real life you would normally get much further without a > problem, but that is the manufacturer's guarantee. You read the > explanation of what the timeout problem is? That's what probably brought > the array down, and until it's back the raid code can't try and fix it. > So it's *likely* that once the array is back up, this problem will go > away. Read errors are not a sign of a failing drive. > > I've just looked at your smartctl output, and I think you need to do a > "-x" on the Seagate. Look at the output from my Barracuda ... > > https://raid.wiki.kernel.org/index.php/Drive_Data_Sheets#ST3000DM001_.282014.29_3_TB > > Note that it says "SCT Error Recovery Control command not supported" :-) > > But what you want to look for is lines like > > 5 Reallocated_Sector_Ct PO--CK 100 100 010 - 0 > > In other words, the drive hasn't had to do any real recovery, and is > healthy - all the sectors are where they should be, with no fancy > jiggery-pokery to try and keep your data safe. You need to distinguish > between the odd hiccup - which is what your read error *probably* is - > and a serious problem where the drive is beginning to have to work hard > to keep your data safe. Ok, so I will try to force assemble my array. However, smartctl -x reports: 5 Reallocated_Sector_Ct PO--CK 100 100 036 - 38 So my disk is probably not as clean as expected, isn't it? > > Scrubbing? > > https://raid.wiki.kernel.org/index.php/Scrubbing_the_drives > Thanks. > Cheers, > Wol Kind, Alexis.
