Raid 5 dead hype

Why don't you have a petabyte server anon?

>>60337017
another drive could easily die during rebuild

>>60337317
What makes you think having one disk fail in an array would increase the odds of another disk totally failing?

>>60337437
This. I don't understand the hype. There's a periodic scrub anyway that reads all the data so why would a rebuild cause any problems?

>it's still good it's still good

Christ you sound like some whiney wintard hanging on to vfat for dear life. Just join the 21st century already and run ZFS.

>>60337437
Just make sure all your drives come from different lots. If they were manufactured sequentially, their odds of dying roughly simultaneously are higher.

>>60337533
>ZFS
>21th century
Pick one. ZFS is old. The cool kids use btrfs now gramps.

>>60337017
The rebuild times on RAID5 are high. The bigger the discs, the worse it gets. Past 4TB disks, I would do RAID6, or one of the ZFS RAIDZ things. RAID 10 wastes to much space for big disks Much past 4TB, or past 10 disks, and you're going to want ceph style distributed storage.

But that said, RAID is dead, long live RAID!

>>60337017
you'd think it would just corrupt a 64k stripe, but people make it sound like it hoses the whole array

>>60337017
Only true about RAID 5 being dead when your capacity exceeds 10.8TB at which point you will most certainly encounter a UER which will kill the rebuild.

>>60337437
Stress on the drive as it undergoes hours or days of rebuild, especially with consumer drives which are not meant to be run at 100% constantly.

>>60337583
You should chose your RAID based on the purpose of the array.

RAID 10's are perfect for high random access (for a raid anyway), rebuild performance or even sequential access. RAID 5 for high read ratio, raid 6 because your array is really big. Raid 4 for SSD redundancy, raid 1 for your desktops or also sequential.

>>60337579

>2005
>old

Tenyearold detected.

>>60337869
you are just fucking old if you think 12 year old software isn't old

>>60337579
Fairly good bait.

ZFS is more mature and has a much larger development team behind it. Btrfs has a hard time even catching up.

>>60337017
Raid 6 is better.

>>60337907
When it comes to file systems anything less than 5 years old isn't even trustable for non production use.

>>60337958
RAID5 takes less i/o for writes and provides more space if you don't need the extra redundancy.

>>60337978
This is why you will lose your data.

>>60337907
I still run SBS2003 for myself. Why? <4Gb RAM, and provides exchange, sharepoint, file/print, vpn etc...

Not as fancy, but can practically run it on my phone these days.

>>60338011
My data gets backed up bro, raid and zfs are not backup solutions.

>>60337017
>I've heard a lot of flak about raid 5 being dead

Those are HDD shills that want to pretend coding theory doesn't exist and the only way to protect data is to have it in triplicate.

What is the best redundancy method for a 8TB volume?

OP here, ZFS isn't an option as I want the ability to grow the array and I'm not about to let my FS eat all my ram. I have 4 bays to work with and just can't justify sacrificing 2 to the gods of chance.

>>60337998
RAID 5 sucks cuz if you're away from the server one HD dies you're dead in the water.

Also there's a higher chance for 2 HDDs to fail.

RAID6 is king tier.
RAID10 is GOD tier.

>>60337017
Get a 6TB drive and back up the contents. Then create a new array with the new drives and copy the data over. Faster and safer than doing 4 rebuilds like a tard.

>>60338186
Was never going to do 4 rebuilds lol. dd is my friend.

>>60338089

ZFS is the best option for growing arrays.

File: download.jpg (4KB, 259x194px) Image search: [Google]

4KB, 259x194px

>>60338292

>>60338089
>grow the array
It adds some different rules to how you grow it but I'm willing to work with it for what it offers. Use lz4 compression, it can work wonders on your data.
Especially the fact that VDEVs boost random I/O. Each one you add adds more random read and write capacity.

>FS eat all my ram
Much like disk cache in linux your ZFS ARC can evict data instantly when other programs need it.
htop just doesn't show how much ZFS uses in yellow so you see the whole thing being used when it's all readily available.

I've installed it before as root on a 2GB laptop and it worked fine for general shitposting and could run minecraft.
htop showed all ram used all the time but everything could run and evict ARC when necessary so it actually performed better than ext4 on that 5400 rpm hdd because of all the aggressive ram caching.

File: 1494101647964.jpg (116KB, 400x800px) Image search: [Google]

116KB, 400x800px

>>60337579
t. runs-unstable-file-system

>>60338109
RAID5 is still redundant
RAID6 is wasteful if you don't need it
RAID10 my favourite, but 50% bigger RAID6 arrays w/8 drives

>>60338089

>I'd rather have idle ram empty rather than take advantage of caching

>>60337017
>there is a good chance during rebuild that another of the drives will have a URE and boom goes the array
And that is the reason why many including the Multi Disk HOWTO states that arrays should be built with disks from different batches.

Remember: the data is most likely more worth than the disks. So replace one disk each year, every year.

Alternative 2 is a more complex array: RAID 6 or nested arrays, such as a RAID1 of two RAID5 sub arrays. That will cost a lot more disks though.

>>60338568
You should not assume shit you don't know. The bulk of my ram goes to postgres indexes.

>>60337437
>What makes you think having one disk fail in an array would increase the odds of another disk totally failing?
Because they're generally all from the same lot and will all die around the same time.

>>60340071
t.poorfag too poor to run dedicated file server

i just put together a 12tb raw, 8tb usable raidz-6 server.

by just, i mean 2 months ago. it boots, i just cba to set it up

also I fucked the file table on my desktop, posting from my laptop

storage is gay

>>60340847
sadly, this...
just go with raid1, dont make large filesystems - whats even the point except posting a screen of your 20tb almost full screens like a faggot (if you need large filesystems because database or similar, you are already barking at the wrong tree and should consult with a storage guy that knows his shit)
buy smaller but more disks(eg 4x3gb instead of 2x6gb or whatever faggots hype these year), dont pair disks from same batches and you are good to go

>>60341317
What do you mean with don't pair disks from same batches?

>>60337017
Raid 5 with good drives and controllers is fine for bulk storage.

>>60341471
probably what >>60337578 said