Are consumer grade NAS silent data killer DA BOMBA due to lack of bit rot protection?

[traderjay]

After familiarizing myself with the awesomeness of ZFS and FreeNAS, it makes me wonder if those crappy consumer grade NAS are just silent DATA KILLERs and giving customers a false sense of security? I mean very few of them have bit rot protection...?

This picture below (South Africa winery) was taken in 2005 so it has been more than ten years. The image was originally stored on an NAS without bit rot protection and experienced corruption due to the silent killer:

 

[maglin]

To my knowledge ZFS is the only structure providing a high level of bit rot protection but even that relies on the person setting up the array.


Sent from my iPhone using Tapatalk

 

[SweetAndLow]

People who buy those consumer grade systems have no clue what bit rot is and probably wouldn't care if they lost some files. I'm also pretty sure those units don't advertise that kind of data protection. Heck I bet most wouldn't survive a HDD failure.

 

[Ericloewe]

Heck I bet most wouldn't survive a HDD failure.

I wouldn't go that far. In combination with the average user of those, definitely. Some of the dodgier ones might fall into the category, though.

it makes me wonder if those crappy consumer grade NAS are just silent DATA KILLERs and giving customers a false sense of security

"Data killers" is a bit of an exaggeration. False sense of security, though? Definitely.
Your average person is, quite simply, ignorant and incompetent (this is valid for almost any discipline, there are plenty where I'm ignorant and incompetent).

If you allow me to express some philosophical thought, here's an opinion of mine (bonus opinion: I'd make you pay for it if I called myself an "analyst"):

As a society, we're too focused on the creation of bureaucracy. Proper archival takes a backseat to the creation, which people do gladly. Photography and other things are just an extension of this bureaucratic way of thinking that defines society, bound by the same forces.

 

[jgreco]

People who buy those consumer grade systems have no clue what bit rot is and probably wouldn't care if they lost some files. I'm also pretty sure those units don't advertise that kind of data protection. Heck I bet most wouldn't survive a HDD failure.

That's unduly unfair. Those systems are basically the same as what was being done with FreeNAS and UFS prior to UFS support being dropped.

They're essentially a little Linux PC with some hard disks, usually running ext3 as a filesystem, which lacks integrity checking, just as UFS lacks. They also typically lack ECC protection of the host system, which isn't *as* important because data doesn't rest for long in the system memory of those units. Bit rot on disk is an unusual but still real thing.

As with FreeNAS, most of them will handle a HDD failure just fine. Since the average user lacks the ability to log in to many of these units and poke directly at the CLI, usually the disk replacement feature actually works pretty well.

But without some form of data protection and checksum (BTRFS, ZFS, etc) they're going to be vulnerable to corruption.

 

[traderjay]

And with today's super high density HDDs doesn't that make data corruption or bit rot even more pronounced?

 

[CookiesLikeWhoa]

Technically wouldn't any system suffer from bit rot? Leave a picture sitting on your desktop HDD long enough and you could probably fall victim to bit rot.

 

[jgreco]

And with today's super high density HDDs doesn't that make data corruption or bit rot even more pronounced?

We'd think so, but ZFS suggests that actual corruption while at rest on a HDD seems to be a relatively unusual event. Of course, your typical NAS could introduce single bit errors elsewhere too. Since we suggest designing FreeNAS systems with ECC and quality components, it is possible that we see fewer data corruption events on the platform, and then have ZFS doing its checksum and detection/correction on top of that.

Technically wouldn't any system suffer from bit rot? Leave a picture sitting on your desktop HDD long enough and you could probably fall victim to bit rot.

A system that detects and corrects bit rot arguably doesn't "suffer" from bit rot.

 

[Ericloewe]

We'd think so, but ZFS suggests that actual corruption while at rest on a HDD seems to be a relatively unusual event.

Yeah, there hasn't been a clearly noticeable increase with disk density. There might be one, but it's not apparent without a formal analysis.

I'd chalk it up to fancy error correction internal to the drives, plus fancy modulation schemes that scramble data to give it nice, juicy statistical properties that are advantageous for keeping tons of bits packed tightly together as magnetic fields.

 

[jgreco]

Yeah, there hasn't been a clearly noticeable increase with disk density. There might be one, but it's not apparent without a formal analysis.

I'd chalk it up to fancy error correction internal to the drives, plus fancy modulation schemes that scramble data to give it nice, juicy statistical properties that are advantageous for keeping tons of bits packed tightly together as magnetic fields.

My conclusion's similar as well. Actually it's freakin' amazin' if you think about it.

 

[Arwen]

To my knowledge ZFS is the only structure providing a high level of bit rot protection but even that relies on the person setting up the array.

Linux's BTRFS file system does support bit-rot detection, and if redundancy is included, bit-rot
protection. But apparently BTRFS uses lesser, (aka faster), checksumming routines... So I'd trust
ZFS more.

 

[Ericloewe]

Wasn't BTRFS configurable with several checksums?

 

[jgreco]

Not that I know of, but it isn't clear why this would be an issue. Checksum errors are incredibly unlikely to begin with on a properly designed system, and it'd be like hitting the lottery for an error to crop up and have the checksum corrupted in such a way that it passed.

 

[Arwen]

There is a BTRFS enhancement in progress to allow different checksum algorithm.
Specifically the current CRC-32C, (32 bits), could be replaced with something that
can go up to 256 bits for metadata. And upto 4KB for data blocks.

My concern is that when the current CRC-32C is used for very long data blocks, it
has less chance to detect problems, than a longer checksum. Ideally, some math
should be done and limit the data block length to something the checksumming
algorithm can detect bit flips well. (And yes, with Terror Bytes of disk space, we
are getting to the point of experiencing statistical annomolies.)

All that said, at present I don't have any plans to change my single disk, (SSD),
netbook to ZFS based root file system. Looks like when I can move to Linux 4.5
kernel, I can get something equivelant to "copies=2", (BTRFS data=dup). And
perform the change live.

Note: I mis-spelled "Terabytes" on purpose to indicate the horror of how much data
we now store, even at home!

 

[styno]

There is a BTRFS enhancement in progress to allow different checksum algorithm.

Now I am curious what version of BTRFS Synology is using atm. and if they use it 'out of the box'...

 

[Arwen]

Now I am curious what version of BTRFS Synology is using atm. and if they use it 'out of the box'...

Linux BTRFS is a combination of Kernel and BTRFS-Progs, (userland package/programs).
When using BTRFS, it is recommended you use recent kernels and userland. Bug fixes are
an issue, since you need to upgrade the kernel to get certain ones fixed.

In my opinion, Linux BTRFS should have gone stable with mirroring, JBOD, stripping and
sparing. Then, only bug fixes applied. Next, forked for experimental RAID-5/6, (and maybe
triple parity). Whence parity RAID was stable, (it's NOT now), then make it stable and
combine it with the mirror stable code. Newer features should be a fork just like in the past
with EXT3/4.

By the way, BTRFS is not as corruption proof as ZFS. Just a few days ago I read that a file
rename was not COW, (Copy On Write);

https://btrfs.wiki.kernel.org/index.php/FAQ#What_are_the_crash_guarantees_of_rename.3F

 

[mrichardson03]

Now I am curious what version of BTRFS Synology is using atm. and if they use it 'out of the box'...

Not sure what version exactly, but they're implementing BTRFS on top of regular Linux software raid because of the lack of stable RAID-5/6 support. You get bit rot detection, but not correction.

It's one of the main reasons I have a ZFS box now.

 

[Ericloewe]

Not sure what version exactly, but they're implementing BTRFS on top of regular Linux software raid because of the lack of stable RAID-5/6 support. You get bit rot detection, but not correction.

It's one of the main reasons I have a ZFS box now.

Ouch, that's hacky.

 

[jgreco]

Ouch, that's hacky.

Not really any worse than what FreeNAS did for encryption.

 

[Ericloewe]

Not really any worse than what FreeNAS did for encryption. :)

My thoughts exactly.