- 2005.10.16, 13:51
- RAID šobrīd ir viena milzīga problēma. Divas, īstenībā, bet otra izriet no pirmās.
Suppose you have three drives in a RAID 5. If it takes 24 hours to replace and reconstruct a failed drive, one is tempted to calculate that the chance of a second drive failing before full redundancy is established is about .02/365, or about one in a hundred thousand. The total probability of a double failure seems like it should be about 6 in a million per year.
Our double failure rate is about 5 orders of magnitude worse than that - the majority of single drive failures are followed by a second drive failure before redundancy is established. This prevents rebuilding the array with a new drive replacing the original failed drive, however you can probably recover most files if you stay in degraded mode. It isn't that failures are correlated because drives are from the same batch, or the controller is at fault, or the environment is bad (common electrical spike or heat problem). The fault lies with the Linux md driver, which stops rebuilding parity after a drive failure at the first point it encounters a uncorrectable read error on the remaining "good" drives. Of course with two drives unavailable, there isn't an unambiguous reconstruction of the bad sector, so it might be best to go to the backups instead of continuing. At least that is the apparently the reason for the decision.
Dzīves realitāte ir tāda, ka nākot klāt lielajiem diskiem, Linux Software RAID (un, iespējams, biezie hardware RAID arī) loģika ir neglābjami novecojusi.
Kāds ir Linux RAID modus operandi? Raid masīvs strādā:
1) Tikko uz kāda no diskiem tiek detektēts "bad block", tas disks tiek nomarķēt "failed" un izņemts no masīva. Sekojoši, redundancy ir pazaudēts.
2) Kamēr viens disks ir izņemts, nākamais atrastais "bad block" (uz pāri palikušajiem diskiem) būs catastrophic failure kad viss masīvs tiek aizsūtīts pa pipelēm.
Un kamēr viens disks ir down, tev ir vairākas stundas kamēr tu ieliksi jaunu disku, un lūgsies lai sinhronizēšanas laikā kādā no palikušajiem diskiem neatrodas kļūda, kas jau būtu fatāla.
Kur šeit ir loģika? Loģikas nav. Pirmais disks (1) īstenībā nav beigts, viņš ir pilnīgi perfektā darba kārtībā. Lielajiem mūsdienu diskiem "bad block" ir norma - jo bloku uz diska ir miljardi, un nav brīnums, ka kāds izrādās defektīvs. Priekš tam uz diska ir rezervēta vieta, un sliktie sektori tiek automātiski pārmapoti uz kādu no rezervētajiem sektoriem, un disks turpina strādāt it kā nekas nebūtu noticis!
Atkārtoju vēlreiz - īstenībā disks ir pilnībā darba spējīgs, un tā visi pārējie sektori ir pieejami un nolasāmi. Kļūda bija tikai vienā sektorā, un tas ir normāli - lieliem diskiem tas var gadīties.
Bet ko dara debīlais RAID? Debīlais RAID dēļ viena slikta sektora (tikai viena kļūdaina lasīšanas vai rakstīšanas pieprasījuma dēļ!) disku pilnībā noraksta kā nederīgu. Disku izgāž, it kā viņam būtu sadegusi elektronika, vai viņš būtu pilnībā nelasāms! Varbūt tā bija pieļaujams agrāk, kad diski bija 200mb vai 2gb lieli, bet realitāte ir tāda, ka tagad diski ir 200gb un 400gb lieli. KernelSummit jau 2001 gadā par to runāja, bet neizskatās, ka kaut kas būtu izdarīts.
Ko RAIDam vajadzēja darīt? Vajadzēja to beigto sektoru nolasīt no pārējiem diskiem (tas tiek izdarīts), bet nevis nofailot draivu, bet mēģināt to info ierakstīt kļūdainajā diskā vēlreiz. Ir ticams, ka tas izdosies, jo diska iekšas (firmware) jau būs paspējušas pārmapot slikto sektoru.
Ko es tikko kā redzēju. Lasīšanas kļūda uz /dev/sde1. (Sekundārā SATA kontroliera pirmais disks). Automātiski /dev/sde1 tiek atvienots no RAID (set disk failed).
Lai pārbaudītu ar badblocks, es izmetu to no masīva armdadm /dev/md0 --remove /dev/sde1
Palaižu badblocks skanu write režīmā (kas visus datus pārraksta, ar, piemēram0xAAun pēc tam nolasa, un pārbauda vai lasās pareizi). Divas reizes.badblocks -p 2 -n -s -v /dev/sde1
(-p 2: izpildīt 2 reizes, -n: "destruktīvais" rakstīšanas režīms, -s: rādīt progresu, -v: verbose)
Neatrodas neviena kļūda (jāpiezīmē ka skans neaizņēma 10 vai 20 minūtes - tas ilga vairākas stundas). Īsāk sakot, pēc skana rezultātiem noskaidrojas, ka RAID nomarķējis disku par beigtu pilnīgi nepelnīti.
Liekam atpakaļ:mdadm /dev/md0 --add /dev/sde1, un gaidam 2 h kamēr RAID labpatiks nosinhronizēties.
Lielajiem diskiem vispār ir tāds gļuks, ka viņi "nezin" vai sektors ir slikts, pirms tam nav mēģināts piekļūt (nolasīt).
Vispār, pirms disku likt pie sistēmas, būtu jēga to visu izdzīt cauri arbadblocksar write testu, bet tas ir baigi ilgi. - 8 rakstair doma
- 16.10.05 14:05 #
-
Ak dievs, vatt, it kā kāds svētdienas rītā dod drāzienu par kaut kādu raid, kas pavisam asocējas ar bērnības policijas reidiem.
- Atbildēt
- 16.10.05 16:21 #
-
Man vienmēr bija licies, ka diska kontrolieris "uzraujoties" uz bad bloka, _uzreiz_ nomapo/realokē to uz rezerveetu (labu) bloku absolūti seamless - t.i. - neatgriežot nekādu kļūdu ides/scuzzy/raid kontrolierim. Pēc tava teiktā, izrādās, tā vis nav...
Papildus piedāvātajam variantam - sastopoties ar i/o error, mēģināt uztaisīt vienu kārtīgu retry, otrs variants varētu būt - raidam pašam prast rīkoties ar bad sektoriem - pašam uzturēt kaut kādu relokāciju tabulu un rīkoties ar to. - Atbildēt
- 16.10.05 18:13 #
-
imo tā vajadzētu būt.
visādā ziņā man ir kādi 8 serveri ar Linux software RAID1 (uz SCSI gan nevis ATA diskiem), un problēmas ir bijušas tikai 1x pēdējo 8 mēnešu laikā - un pat tad tas joprojām nav skaidrs, vai tās bija konkrēti tieši RAIDa problēmas.
HP-UXi, ko adminoju principā tikai uz sava proprietārā software RAIDa vien sēž. Tiesa gan, viņiem tas imho bija nedaudz savādāk organizēts kā Linuxa.
Un tie softRAIDotie serveri tiek izmantoti VISAI intensīvi. - Atbildēt
- 16.10.05 18:33 #
-
nu es varu teikt ko es redzēju: bija kautkāda I/O kļūda, dēļ kura disks tika izfeilots no masīva ārā, bet badblocks tam diskam vairs pēc tam neko sliktu neuzrādīja.
- Atbildēt
- 16.10.05 18:38 #
-
ata5: status 0x35 { DeviceFault SeekComplete CorrectedError Error }
sense key: Hardware Error
end_request: I/O Error, dev sde, sector tādsuntāds
un disks ārā no masīva. - Atbildēt
- 16.10.05 22:48 #
-
iespējams, ka tiem SCSI diskiem ir bikiņ smalkāk organizēta bad blocku relokācija, ka Linux uz viņiem nefailo. hvz. :) jāskatās.
- Atbildēt
- 17.10.05 00:38 #
-
tiešām, jautājums kāpēc šis error tika izmests. varbūt tam bad block kļūdai ir kāds cits iemesls.
vispār, mana dziļākā sāpe ir tas, ka RAID autori uzskatīja ka katrs sīkākais error ir pamats disku mest ārā no masīva (pakāšot redundancy). un tikai nesen ir izdomāts RAID6, kas redundancy glabā uz 2 diskiem. es šausminos ka tik vienkāršas lietas cilvēkiem tik lēni pielec.
ja es būtu pie ruļļiem, RAID par visiem spēkiem censtos saglabāt disku masīvā, un pirms izmest to ārā, censtos izmantot visus pieejamos datus, un noglabāt tos drošībā. tb, to redundancy, kas atrodas uz "it kā bojā ejoša diska" censtos nolasīt. - Atbildēt