Citat:
Ursprungligen inskrivet av dundermuppen
Jag misstänker att du inte riktigt känner till hur hårdvaruraid fungerar. Hur tror du att ett kort vet om en disk är trasig annat än i de lägen den helt enkelt inte varvar upp ens? Det kontrolleras med checksummor och där blir det direkt uppenbart om det är datakorruption. Riktiga kontrollers gör också fortlöpande kontroller av hela diskytan de tidpunkter som det inte maxbelastas.
Jag ser att du påstår att hårdvarukontrollers skriver ut datat utan att sen kontrollera att det blev skrivet? Har du någon fakta bakom det påståendet och helst då en lista på vilka kontrollers som bara skriver i blindo?
En annan fråga. Kan du exemplifiera vilka typer av hårdvarukontrollers du pratar om här? LSI? Adaptec? Promise? Highpoint? SiliconImagebaserade? Intel ICHxR? Andra?
Bara så att vi pratar om samma sak.
Jag hoppas att du inte lever i villfarelsen att din zfs kan ersätta backup
Nej jag tror inte ZFS ersätter en backup. Men jag kör en hemma lösning för några tusenlappar. Jag har inte råd med en tape backup. Kort sagt, jag kör utan backup. Gör inte de flesta hemanvändare det? Hur många har t.ex. tape backup hemma?
Angående HW raid och data korruption. Jag tycker det är jättebra att ni frågar eftersom jag vill självklart lära mig ZFS begränsningar. Eftersom jag är "nykär" tänker jag inte i de banor som ni gör (Fan, ZFS är så enkelt och snyggt så man kan inte tycka illa om det). Era relevanta frågor vill jag oxå ha svar på, förstås. Jag vill ju köra det bästa möjliga för en billig peng, som alla andra vill. Om det nu visar sig att ZFS inte håller måttet så vill jag inte köra det förstås. Men SUN brukar inte komma med tveksamheter i sina reklamkampanjer, på samma sätt som t.ex. IBM eller MS? Men om ni sett SUN göra det, så vill jag gärna veta mera om det.
Jag har dröjt med svaren angående om HW raid korruptar data, eftersom jag frågat runt för att jag vill vara 100% säker och jag har inte fått länkar till artiklar som går igenom alla HW raid, kort för kort och undersöker hur de behandlar data korruption. Ingen har visat mig nån sån artikel, men eftersom Dundermuppen verkar känna till detaljerna om såna här saker, så vill jag och flera andra här, gärna läsa hans länkar. Dundermuppen kan du posta dem? Vore intressant.
Här pratas om en HW raid undersökning på fysikcentrum CERN, CERN lagrar ju massor av data för sin stora partikel accelerator och borde veta vad de sysslar med?
http://opensolaris.org/os/community/zfs/docs/zfs_last.pdf
Measurements at CERN
● Wrote a simple application to write/verify 1GB file
● Write 1MB, sleep 1 second, etc. until 1GB has been written
● Read 1MB, verify, sleep 1 second, etc.
● Ran on 3000 rack servers with HW RAID card
● After 3 weeks, found 152 instances of silent data corruption
● Previously thought “everything was fine”
● HW RAID only detected “noisy” data errors
● Need end-to-end verification to catch silent data corruption
Mera prat om HW raid:
http://74.125.77.132/search?q=cache:DA0-6Ufp8a8J:gridmon.dl.a...
One failure for every 10**15 bits read.
RAID arrays may not handle block re-maps satisfactorily or take so long
that the system has given up.
RAID5 not perfect protection – finite chance of 2 disks failing!
SCSI interconnects corrupts data or give CRC errors
Filesystems (ext2) corrupt for no apparent cause (EXT2 errors)
Silent data corruption happens (checksums are vital).
Fixing data corruptions can take a huge amount of time (> 1
week). Data loss possible
En teknisk artikel om varför Raid 5 bör undvikas, säger att Raid 5 kontrollerar inga läsningar:
http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt
"When a drive returns garbage, since RAID5 does not EVER check parity on
read (RAID3 & RAID4 do BTW and both perform better for databases than
RAID5 to boot) if you write a garbage sector back garbage parity will
be calculated and your RAID5 integrity is lost! Similarly if a drive
fails and one of the remaining drives is flaky the replacement will be
rebuilt with garbage also propagating the problem to two blocks instead of
just one."
Sen skriver lite blandat folk så här till mig:
"Until a few years ago, the understanding of "HW RAID doesn't proactively
check for consistency of data vs. parity unless required" was true. But
LSI had added background consistency check (auto starts 5 mins after the
drive is created) on its RAID cards
...
This is exactly the point why RAID6 should always be chosen over RAID5,
because in the event of a wrong parity check and RAID5 the controller
can only say, oops, I have found a problem but cannot correct it - since
it does not know if the parity is correct or any of the n data bits. In
RAID6 you have redundant parity, thus the controller can find out if the
parity was correct or not. At least I think that to be true for Areca
controllers As I said I know that our Areca 1261ML does detect and correct those errors - if these are single-disk corruptions
...
dual-disk corruption can (to my understanding) never be healed by the HW raid controller since there is no redundant information available to check against.
...
Almost all old RAID designs have holes in their logic where they are insufficiently paranoid on the writes or read, and sometimes both. One example is the infamous RAID-5 write hole.
Look at simple example of mirrored SVM versus ZFS in page 15-16 of this presentation:
http://opensolaris.org/os/community/zfs/docs/zfs_last.pdf
Critical metadata is triple duped, and all metadata is at least double-duped on even a single disk configuration. Almost all other filesystems are kludges with insufficient paranoia by default, and only become sufficiently paranoid by twiddling knobs & adding things like EMC did. After using ZFS for a while there is no other filesystem as good. I haven't played with Linux BTRFS though maybe it has some good stuff but last I heard was still in alpha.
...
AFAIK, HW raid usually do not check the validity of data unless a disc returns an error.
....
My understanding is that ordinary HW raid does not check data correctness. If the hardware reports failure to successfully read a block, then a simple algorithm is used to (hopefully) re-create the lost data based on data from other disks. The difference here is that ZFS does check the data correctness (at the CPU) for each read while HW raid depends on the hardware detecting a problem, and even if the data is ok when read from disk, it may be corrupted by the time it makes it to the CPU.
Så det verkar vara blandade bud. Det verkar som vissa HW raid kort börjar först på senare år få viss felkontrollering, men inte vidare sofistikerad. Det är mera ett påhäng och en efterkonstruktion. Medan många andra HW raid skriver i blindo.
ZFS designades från grunden upp, med felkontrollering i åtanke, det är en av SUNs högsta prioriteter i serverhallarna, eftersom datamängderna blir större, så blir såna här fel vanligare och ett reellt problem för Enterprise företag, dvs SUNs kunder. SUNs kunder klagar och kräver lösning.
Här ser vi dock att ZFS inte läser tillbaka allt i RAM omedelbart efter en skrivning, vilket jag felaktigt fått för mig. Istället kontrolleras datat efter varje läsning, om datat man fått fortfarande är korrekt. Detta är ju bättre. Tack till Dundermuppen som önskade mer utredning om detta!
"When ZFS writes the data, it also stores a checksum for the data. When the data is read, it is checksummed again and the checksum is verified against the stored checksum. It is not possible to compare with data in RAM since usually the RAM memory is too small to cache the entire disk, and it would not survive reboots."
...
One of the design principles we set for ZFS was: never, ever trust the
underlying hardware. As soon as an application generates data, we generate a checksum for the data while we're still in the same fault domain where the application generated the data, running on the same CPU and the same memory subsystem. Then we store the data and the checksum separately on disk so that a single failure cannot take them both out.
When we read the data back, we validate it against that checksum and see
if it's indeed what we think we wrote out before. If it's not, we employ all
sorts of recovery mechanisms. Because of that, we can, on very cheap
hardware, provide more reliable storage than you could get with the most
reliable external storage. It doesn't matter how perfect your storage is, if
the data gets corrupted in flight - and we've actually seen many customer
cases where this happens - then nothing you can do can recover from that.
With ZFS, on the other hand, we can actually authenticate that we got the
right answer back and, if not, enact a bunch of recovery scenarios. That's
data integrity.
Här står ganska utförlig info om ZFS och data säkerhet av ZFS huvudarkitekt:
http://opensolaris.org/os/community/zfs/docs/zfs_last.pdf
Sen fanns det snubbar som sågade HW raid 5 som något dåligt och det ska undvikas. Här finns massa tekniska artiklar om varför de tröttnat på HW raid 5 och undviker det numera:
http://www.baarf.com/
"I lean towards simple mirrors these days. But if you are comparing with "Hardware RAID" what you mean is RAID-5 typically which is something I try to avoid now. In that comparison ZFS RAIDZ2 still comes out ahead of all RAID-5/6 setups IMO."
Emigrating12
Angående att byta ut diskarna mot större, så går det utan problem. Man tar loss en disk och stoppar i en större och reparerar raidet. Det är typ ett kommando, typ
#zpool replace disk3
Så skriver den bara det aktiva datat på den nya disken, ingen formatering innan krävs, förstås. Den skriver inte tomma data. Ju snabbare CPU du har desto snabbare går det förstås. Inga config filer eller nåt sånt. Typiskt krävs det ett kommando.
Du kan ta ut diskarna i ZFS raidet och stoppa in i vilken ZFS dator som helst, t.ex. Apple OS X och importera raidet utan problem. Du kan t.om. byta endianess mellan olika CPU arkitekturer utan problem. ZFS sparar all data endian neutralt.
Jag gillar att ZFS partitioner är dynamiska, de krymper och växer i storlek allteftersom du vill. Du kan sätta gränser, typ, den får inte växa mer än 100GB. Så tanken är att varje användare ska ha en egen partition (dvs filssystem). Ingen formatering eller så. Det är lika enkelt och snabbt som att skapa en katalog.
NakedApe,
Jag vet att det hela tiden sker massa kontroller överallt, jag är inte okunnig om det. Men alla förlitar sig på att hårdvaran tar hand om felkontrolleringen. T.ex. skrev jag att 20% av ytan på en stor disk är dedikerad till felkontrollering, så jag är inte ovetandes om att det sker felkontroller. Men ZFS litar inte på någon hårdvara, och är designad för att saker kommer att gå snett - och kan handskas med det. Som Bonwick skriver:
"The job of any filesystem boils down to this: when asked to read a block, it should return the same data that was previously written to that block. If it can't do that -- because the disk is offline or the data has been damaged or tampered with -- it should detect this and return an error.
Incredibly, most filesystems fail this test. They depend on the underlying hardware to detect and report errors. If a disk simply returns bad data, the average filesystem won't even detect it."
Jag vet att det även behövs backup, men jag har inte råd med en tape backup. Jag kör utan backup och håller tummarna!
"Såvitt jag vet stödjer inte ZFS expansion av RAIDZ/RAIDZ2-arrayer. Både det och förminskning av arrayer (genom att plocka bort en disk) lär vara på gång dock."
En ZFS raid består av flera grupper av diskar, dvs vdev. Du kan adda en ny grupp, om du vill, till ett ZFS raid. Men om gruppen består av bara en disk så har du ingen redundans i den gruppen. Det är illa. Har du redan ett zfs raid med 4 diskar, så bör du adda en ny grupp som har säkerhet även i den gruppen. T.ex en grupp med 2 diskar som speglar varandra så du har säkerhet även i den nya gruppen. Eller en likadan grupp om 4 diskar.
Du kan alltså inte öka på/minska antalet diskar i en redan skapad grupp. Men den funktionen är på gång. Att bara byta ut diskarna mot större är inga problem.
Saddam skrev
"Som jag sagt, en enkel CPU + 4 diskar i ZFS ger dig 120MB/sek. Stoppar du i 7 diskar får du mycket mera speed. etc. Jag har skrivit om typiska överföringshastigheter med ZFS i tidigare inlägg."
NakedApe skrev
"Den här typen av generaliserande påståenden gör att man omöjligt kan ta dig på allvar. Vad pratar vi för kontrollerkort, buss, diskar, arraytyp, dataset och I/O-karakteristik? Är det stora läsningar, små skrivningar, blandad access etc?"
Jag har bara skrivit ned några typiska uppgifter vad folk rapporterar. Då har de typiskt en vanlig AMD dual core modell klenare, och några SATA 7200 varvs diskar i ett chassi. Jag föreslår att du mailar dem och begär en fullständig redogörelse om du vill veta mera? Dont shoot the messenger? Jag vet tyvärr inte mer än det jag läst av deras redogörelser.
4 diskar = 120MB/sek (sustained read/write)
http://blogs.sun.com/barts/entry/new_home_server#comments
7 diskar = 440MB/sek
http://opensolaris.org/jive/thread.jspa?threadID=54481
48 diskar = 2 GB/sek
http://milek.blogspot.com/2006/11/thumper-throughput.html
Här har du några Bonnie++ benchar ZFS vs Linux vs BSD
http://www.phoronix.com/scan.php?page=article&item=os_threewa...
RonnyLov skriver att hans ZFS server trycker ut 90MB/Sek på en GBit nätverk numera. Och hans budget låg på 7000-8000, det var alla 5 st terabyte diskarna som kostade mest.
"I samma svepande anda påstår du att ZFS är billigare än hårdvarubaserad RAID men du har inte ställt upp några kriterier överhuvudtaget på vad behoven/kraven är. Det är inte särskilt svår att föreställa sig ett scenario där ZFS extra processorlast gör det till ett dyrare alternativ om man räknar in elförbrukning (vilket i de allra flesta fall är en betydligt större kostnad än inköpspriset)."
Åh, detta är väldigt ovetenskapligt som du märker. Jag gör inte anspråk på att skriva en vetenskaplig artikel med 23 källor. Mina luddiga kriterier, var att
du vill bygga en enkel hemma filserver och att du spenderar typ 7000kr eller så. För den summan vill du få bästa möjliga prestandan och att dina data är säkra. Jag kanske var lite otydlig med att detta gäller hemma filserver. Tyvärr har jag inte skrivit några formella kravspecar, om du hoppades på det.
Sen har jag svårt att se att ZFS extra cpu last gör det till ett dyrare alternativ än ett HW raid. Hur mycket kostar några procent extra cpu last, i watt? Ett par tusen kronor??? Vi pratar om en hemma filserver. De har ofta klena CPUer. Det finns inte en chans att de spenderar så mycket cpu så den summan blir några tusen.
ZFS är numera optimerat så det kräver ungefär lika mycket CPU som ett vanligt filsystem, har jag läst nånstans på SUNs ZFS mail listor.
"Jag instämmer i emigrating12s analys: du är ovillig eller rent av oförmögen att inse att alla inte ser ZFS som "den ultimata lagringslösningen" och alla argument för att andra lösningar kan ge samma--eller bättre--säkerhet, prestanda etc, hur insatta eller kompetenta de än är så ogiltigförklarar du dem för att de inte passar din bild av hur saker och ting förhåller sig."
Det var tråkigt att du känner så. Jag håller med om att denna tråd kanske är vinklad för att jag utgår från mig själv och min situation: "billig hemma server för några tusen". Och däri får inte ett HW raid kort för 5000kr plats i budgeten, när hela budgeten är på kanske 7000kr.
Men vi kan ändra på kriterierna om du känner att jag är enkelspårig? Vi tar istället en budget på 5000+7000=12 000kr för en hemma filserver så kan vi även få in HW raid med i diskussionen? Jag vet dock inte om såna billiga kort ger någon vidare säkerhet, enligt det jag fått reda på om HW raid?
"Slutligen vill jag tillägga att jag verkligen gillar både Solaris och ZFS men som jag sade tidigare: man blir lite trött på mässandet."
Det var lite tråkigt att du finner det störande, men jag är lite nykär just nu. Lite svårt att sluta prata om min nya tjej hela tiden. Jag får försöka tona ned lite, och du kanske kan låta bli att titta in i mina ZFS trådar jag skapar?
Moire,
Ja, det är ett problem att om du vill köra ZFS så måste du köra Unix: Solaris, BSD eller Apple OS X. Tyvärr. ZFS är inte portat till andra OS vad jag vet, just nu. Men det kanske kommer eftersom det är öppet?
EDIT:
Här ser vi att en HW raid kan göra felkontroller, när man begär så. Det är typ som fsck i Linux. Problemet är dock att man måste boota om och göra detta i BIOS, du kan alltså inte använda HW raidet under tiden du gör kontrollen. Jag hoppas detta inte gäller för de flesta HW kort?
http://www.rm.com/Support/TechnicalArticle.asp?cref=TEC499467
EDIT2:
Här står utförligt om matematiken kring Raid6 och hur den kan reparera fel:
http://kernel.org/pub/linux/kernel/people/hpa/raid6.pdf
Marc skriver om den artikeln:
"The paper explains that the best RAID-6 can do is use probabilistic
methods to distinguish between single and dual-disk corruption, eg.
"there are 95% chances it is single-disk corruption so I am going to
fix it assuming that, but there are 5% chances I am going to actually
corrupt more data, I just can't tell". I wouldn't want to rely on a
RAID controller that takes gambles :-)"
Detta är ju inte bra. En HW raid som gissar, och det är chans att den korruptar än mera data? Hmm... Jag tror jag håller mig till ZFS.
