Raid 1 on controllers v. BTRFS

[GreyGeek]

This video explores the error correction capabilities of a hardware Raid 1 controller and compares it to Btrfs's software Raid 1 .
This Linux portion starts at around 16 minutes. Cutting to the chase: Btrfs is superior.

[oshunluvr]

For others reading this (and as GG already knows), even if btrfs was just equal to RAID 1 controllers in error correction, btrfs still wins because of all the added features it brings that other filesystems just don't have.

[vinnywright]

For others reading this (and as GG already knows), even if btrfs was just equal to RAID 1 controllers in error correction, btrfs still wins because of all the added features it brings that other filesystems just don't have.

,,,,,,,,and a big +1 on that .

VINNY

[dibl]

I guess he mirrored his data to make it more comparable to the hardware RAID setup, but do you guys use mirroring or striping for your data? Just curious -- I've always gone with the default multi-drive setup (data striped, metadata mirrored).

[GreyGeek]

Nope, no mirroring. My laptop has only one 600Gh HD. Creating Raid 1 on two partitions would be pointless.

[jlittle]

Nope, no mirroring. My laptop has only one 600Gh HD. Creating Raid 1 on two partitions would be pointless.

But with btrfs, IIUC, mirroring your data on one partition would not be. Sure, with complete drive failure you're looking for backups, but modern drives can go bad gradually when they've run out of replacement sectors; btrfs mirroring of data should (in theory) cope nicely. Maybe a scenario for Wendell to check out...

Regards, John Little

[GreyGeek]

One of my clients was a well known trucking company. I was asked to write certain graphical parts of their truck tracking and communication program that used GPS, VOIP and text msging. The whole package was being written by their in-house developers. During my next to the last week there, their payroll system died and they couldn't get checks out to employees for about ten days. They missed two weekly payrolls. Seems that although they were using Raid 1 across two HD's on separate disk controllers on an IBM AS/400, both disk controller were powered by the same power supply. It died and crashed both disks with abends, the heads carved up the platters surfaces, loosing all their current payroll data. One would think that an operation that big, with trucks moving over all the roads in the US, would have nightly and weekly backups off site. The payroll aside, the truck tracking system was neat. It was displayed on a giant display showing small icons at every truck's location. You could see the icons moving slowing along roads, or parked at stops or destinations. Click on an icon and it would show who the driver was, how long he had been driving that day, how fast he was traveling, his maximum top speed during the trip, etc.... Just about anything you would need to know about a truck, its contents and the driver.

My answer to my client's question of "how often should I back up?" was answered by my question "How much do you want to re-enter?". Even back in the 1980s I was recommending to all my clients that they back up incrementally at noon and evening each day, and a full backup on Saturday evening (or Friday evening if they didn't open on Saturday). Even using Raid (hardware or Btrfs) it is a good practice to make backups at regular intervals and store them off site. Btrfs can't protect if it is smoking!

[dibl]

Even using Raid (hardware or Btrfs) it is a good practice to make backups at regular intervals and store them off site. Btrfs can't protect if it is smoking!

And all the people said, "Amen".

[MoonRise]

And all the people said, "Amen".

+1 "Amen"