All about the unRAID Array, how data is written and how the parity works
Video Statistics and Information
Channel: Spaceinvader One
Views: 82,265
Rating: undefined out of 5
Keywords: linux, unraid, unraid array, raid 5, raid 6, parity, single parity, dual parity, xor, reed solomon, lime technology, lime tech, unRAID, nas, data, how data is stored on a harddrive, ssd, hdd, hard drive, how a hard drive works, home server, server, kvm, docker, qemu, All about the Array, how data is written and how the parity works in unRAID, tutorial, guide, how raid works, how unraid works, difference between raid and unraid, double parity, what is parity
Id: HybwCOVDg9k
Channel Id: undefined
Length: 17min 39sec (1059 seconds)
Published: Fri Feb 03 2017
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.
This video is all about the array and how it works in unRAID. It discusses the 3 different types of drives that make up the array. You will learn how data is both written and stored on a harddisk and an array. You will see how both single and dual parity work to protect your server from hard drive failures. You will see the differences between raid5/6 and the unRAID array. Hope you find it interesting !!
That's OK, but misses out on one of the things UNRAID is moving towards.
At present, by default, when it writes to the array UNRAID first reads the disk it's going to put the data on, and the parity. If the data bit is going to change it then writes the reversed bit to the data and parity drives (Read/Read:Write/Write). The advantage here is that only two disks are spun up.
With 'turbo' mode it instead reads all the data disks (except the one where the data is going, calculates the XOR, then writes the data and parity disks (Read/Read/Read:Write/Write). All drives are spun up.
Why does this matter?
Well, in the first default case the drives have to continually swap between read and write modes - and it turns out there is a latency in doing this. That slows down the overall write speed as the drives are continually swapping modes. In the 'turbo' mode each disk is either in read or write mode; speeding up the overall operation at the cost of more power usage and more disk usage.
The aim is 'auto' which hides all this from the user - but currently it's an option to set.
See http://lime-technology.com/forum/index.php?topic=52122.msg500304#msg500304
Someone did some benchmarking, and in a best (though quite typical blu ray copy) case got :
although less for more disjoint cases.
Oh my very days!
Thank you for explaining how parity works. I always thought it was some kind of ancient magic that allowed parity to work. I'm still not sure i get it 100% ... but your vid has helped.
In your example you use a one bit area on the disk to demonstrate parity.
Might be a silly question... but is parity calculated bit-by-bit in Unraid... if so there has to be some kind of exact and 100% accurate filesystem syncing between read heads and portions of the disc. Afterall even the tiniest inaccuracy in syncronisation between the bits on your HDD and its completely useless.
You know what... i'm not sure anymore... I still think there's a little bit of goblin magic involved.
One of the things that just threw me a bit is when one of my drives went "unmountable" (probably due to a power bump that I didn't catch before my ups battery failed), and couldn't be repaired by mounting the drive offline to replay the Log file.
No physical damage to drive, just corruption of file system.
Only zeroing the log allowed it to come back, but still don't entirely trust it.
Scared the heck out of me. Fortunately I have everything backed up on an offline drobo nas, but should never have happened. Seems that xfs just isn't that robust when mounted in the unraid style.