Gargamel.NU

På grund av sjukdom som aldrig släpper, mycket jobb och fint väder har det tagit alldeles för lång tid mellan mina inlägg. Men vem bryr sig?

Jag har nu avslutat mitt ärende på HP ang. Buggig BIOS, se följande inlägg:
Felanmäld BIOS, del 3
Felanmäld BIOS, forts…
Felanmält buggig BIOS

Det visar sig tillslut att detta är ett kernel-problem.
Jag installerade Kernel 2.6.30 från Kernel-PPA och då fungerade hyperthreading som det skulle. (dessvärre fungerade inte AppArmor och lite andra funktioner med den kerneln).
Så, jag väntar helt enkelt tills 2.6.29 eller 2.6.30 blir tillgänglig.

Jag vill avsluta med att ge HP supporten lite beröm hur de skött hela detta ärende, de har följt upp varje samtal och frågeställning på ett utmärkt sätt. De har varit trevliga och tillmötesgående, så: Hatten av till HP-Supporten, ni överträffade mina förväntningar med hästlängder

Gång på gång dyker denna diskussion upp. På IRC, Forum, telefon och i vanliga diskussioner mellan mig och andra. Det är vad jag får höra, och ett av de som gnäller är också denna blogg ett bevis.

Man måste in och peta i textfiler och i terminaler, det är ALLDELES FÖR SVÅRT!!

Är det verkligen det? Jag håller givetvis inte med.
Anledningen till att denna blogg (precis som många andra linux-bloggar) innehåller så mycket konfigurationsexempel och hänvisningar till terminalen är för att JAG har det intresset. Jag har installerat Linux (Ubuntu) på min fars dator, och använde inte terminalen en enda gång.

Min far använder datorn till att surfa, läsa mail och skriva dokument utan problem. Han är väldigt nöjd med prestanda och funktion. Han håller inte med om att Linux är svårt.

En del påstår att vi har ett kollektivt ansvar att visa hur enkelt Linux är, kanske har de rätt, men jag håller inte med. Varför skall jag göra avkall på mitt intresse för att få trångsynta personer att använda Linux?

Hur som helst. Det finns tydligen fortfarande människor som tror att Linux är en svart terminal med gröna bokstäver. De tror att man måste konfigurera textfiler för att få systemet att fungera. Inget av detta är givetvis sant. Anledningen till att jag, bland många andra, konfigurerar textfiler och kompilerar program är för att det går. Det är möjligt att optimera din dator att fungera som du vill, inte som någon annan har bestämt. Det är enbart fantasin som sätter gränser till funktion och utseende. Så när möjligheten finns, varför inte använda det. Det är inget ett tvång , det är en möjlighet. Det är inte svårt, det är en frihet.

Nu har jag fått ytterligare ett svar från HP

Has the customer checked with Ubuntu support?
It appears to be an issue with Ubuntu and not with BIOS.
Please note that Duo is supported by Windows and Suse Sled Linux. If the custoemr has issues with Ubuntu , then he would neeed to check with Ubuntu,.

Måste testa med SLES för att se om problemet även finns där… *suck*

Jag skrev ju tidigare (i ett bittert och tröstlöst tillstånd) om uppköp, där siade jag om nästa konsolidering… kanske det blir sanning? Det pekar åt det hållet när man läser denna artikel på IDG

HP sneglar väl åt sepaton antar jag, de OEM:ar redan delar av deras dedupliceringsteknik, så varför inte?

Som jag skrev tidigare la NetApp ett bud på Data Domain, detta retade tydligen upp EMC så pass mycket att de också la ett bud. 33% högre, runt 2 Miljarder dollar.

Vem som vinner vet jag inte ännu, men att EMC har dessa pengar är jag relativt övertygad om, men NetApp har nog svårt att “hosta” upp motsvarande summa ur sin stridskassa. Jag följer utvecklingen med intresse…..

Det finns ju en mängd med filsystem och ext4 har ju precis blivit stabilt, varför behövs det ytterligare filsystem?

Det har bland annat med RAID och något som kallas “Unrecoverable read error rate” att göra. Först och främst måste vi klargöra vad vi vill att en RAID skall uppnå. Vi har tre parametrar att “leka” med när vi väljer en RAID-nivå:

• Prestanda
  Detta är ju avgörande för applikationen, vi måste ju tillhandahålla en RAID-nivå och rätt antal diskar för att tillgodose denna prestanda. Olika RAID-nivåer har olika fördelar och nackdelar för prestandan, så beroende på hur accessmönstret som applikationen skapar är de olika RAID-nivåerna bra på olika sätt
• Tillgänglighet
  En av grundaspekterna. Vi vill ju att informationen skall vara tillgänglig även om en (eller fler) diskar går sönder. Också här har de olika RAID-nivåerna olika karaktärer. RAID1 har tillexempel en försumbar prestandaförlust vid en trasig disk, medans RAID5 får en stor negativ prestandaförlust i ett degraderat tillstånd.
• Pris
  Kanske den viktigaste aspekten. Det är alltid denna aspekt som avgör nivån på skyddet. Vi köper oss det skydd vi har råd med, inte alltid den nivå vi behöver.

Oftast väljs en RAID5 på de stora datavolymer vi har, detta för  “RAID-Overhead” inte blir så dyr och kostsam. Utöver detta bygger vi våra RAID-set på stora diskar för att få plats i våra servrar och lagringssystem för att få plats med all information vi “tvingas” spara. Eftersom den “RAID-Overhead” som blir i ett RAID5-set motsvarar volymen av en disk så vill vi också bygga detta med så många diskar som möjligt, allt för att minimera kostnader, så ökar vi samtidigt risken att ytterligare en disk skall gå sönder vid återbyggnaden av en trasig disk.

Vi kan ju i ett RAID5-set “överleva” en trasig disk. Så hur stor är sannorlikheten att ytterligare en disk går sönder när vi återbygger den trasiga disken? Detta är inget jag kan räkna på, det är alldeles för invecklat. Men det finns visa och duktiga personer i branchen som gjort detta, och deras iaktagelser baserat på MTBF (Mean Time Before Failure), och det faktum att diskar inte går sönder helt slumpmässigt, kommit fram till att 10-14 diskar är maximalt antal diskar i ett RAID5-set. Diskarna följer en “bathtub curve” i sin felfrekvens, och har alltså en tendens att gå sönder i början av sin livstid eller när den är utsliten. När en trasig disk skall återuppbyggas så måste samtliga “levande” diskar i RAID-settet läsas, samtliga block, samtidigt som den tillgodoser den normala driftens I/O behov. Alltså jobbar diskarna betydligt hårdare under uppbyggnaden än vid normal drift. Detta ökar sannorlikheten att ytterligare en disk skall gå sönder när en redan gjort det.

Därför skapades RAID6.
Enligt SNIA så är en RAID6 följande:

Any form of RAID that can continue to execute read and write requests to all of a RAID array’s virtual disks in the presence of any two concurrent disk failures.

Så, oavsett vad lagringstillverkaren kallar det så är det RAID6, det bara implementeras lite olika av olika tillverkare och därför får lite olika namn som te.x ADG (Advanced Data Guarding) från HP.

RAID6 fungerar ungefär som RAID5 med den stora skillnaden att vi har dubbla paritets-stripes. Detta innebär att vi kan överleva två trasiga diskar utan att förlora informationen. Vi kan då bygga större RAID-set med fler diskar inblandade, och på så sätt få ner priset på våra RAID-set. Så, fler diskar än 10-14 stycken så är rekommendationerna att köra RAID6 för att få ett tillräckligt skydd på infromationen.

Denna post har hitintills handlat om antalet diskar i RAID-settet, men det finns en dimension till och detta är “Unrecoverable read error rate“. Det är ett läsfel som vi inte kan upptäcka eller korrigera och på SATA-diskar ligger denna faktor på ca: 10¹⁴ bitar är ca: 12 TB och låt oss anta att vi bygger ett RAID5-set med 12st 1TB SATA och en av dessa går sönder och måste återuppbyggas, då måste de restrerande 11 diskarna läsa samtiga block och återbygga paritet/data blocket på “spare” disken, det innebär att 11TB data måste läsas för att kunna bygga tillbaka den trasiga diskarn. Detta är skrämmande nära “Unrecoverable read error rate” för SATA. “Unrecoverable read error rate” har alltså inget med antalet disk, utan enbart med volym att göra. Eftersom volymen blir större och större så blir det praktiska maximala antalet disk i våra raid-set färre och färre. RAID6 är inte någon lösning på detta problem, utan bara ett sätt för oss att “putta snöbollen” framför oss och köpa oss lite “tid” innan detta slår oss i ansiktet. Om inte disk- och bus-tillverkarna lyckas att minska “Unrecoverable read error rate” i samma takt som volymen på diskarna ökar så är detta ett växande problem. Här kommer filsystemen in i bilden. Filsystem som btrfs och zfz har funktionallitet att hantera denna problematik. Detta är, enligt mig, de största anledningarna till att överhuvudtaget titta på dessa typer av filsystem. Sen att vi får ytterligare funktionallitet som “snap-shot” och annat “godis” är det bara en bonus.

Blev uppringd idag av HP-Support angående min tidigare felanmälan. Jag måste säga att jag är positivt överaskad över hur HP hanterat detta.

De kom med några förslag på saker jag skulle testa, givetvis fungerade dessa in (bland annat testa att starta datorn med en annan stömadapter). Jag blir dock lite orolig när de frågade om Windows funger som det skall, vilket det också gör. Jag misstänker att de kommer hänvisa till att datorn levereras med Windows och därför fungerar den som den skall. Men kvinnan på HP-supporten avslutade med följande betryggande ord.

Om datorn startar som den skall med batteri, skall den givetvis också starta med strömadapter, oavsätt vad du installerat.

De sammlade ytterligare information från mig angående problematiken som “third line support” eferfrågat och bad om att få återkomma.

Hitintills har HP skött sig ypperligt, det finns säkert ytterligare anledningar att återkomma i ämnet.