ZFS with one data drive

[lazy7689]

I've scoured the net and can't seem to get an answer to this question.

Is ZFS's protection against bitrot effective with only one data drive?

Thanks in advance.

 

[Relativistic]

Only if you use copies=2 or more. It doesn't have error correcting codes. It only checks the data it reads against a hash (fletcher/sha256/etc). If it doesn't match it will have to be pulled from another part of the drive (copies=2) or another drive.

Using copies=2 will effectively halve the storage capacity of the drive. You may also only use it on critical data. More info: http://blogs.sun.com/scf/entry/solaris_zfs_creating_redundant_copies

 

[lazy7689]

I apologize for my ignorance, but you're basically saying that in order for the error correcting to work, I would either need to duplicate all my data or have mirroring or raid5/6 in place, correct?

I want to prevent bitrot and have the ability to add more drives to the same zpool without incurring the costs of purchasing additional drives to mirror data or for parity. Is there any practical way to accomplish this?

 

[Relativistic]

I apologize for my ignorance, but you're basically saying that in order for the error correcting to work, I would either need to duplicate all my data or have mirroring or raid5/6 in place, correct?

Correct

I want to prevent bitrot and have the ability to add more drives to the same zpool without incurring the costs of purchasing additional drives to mirror data or for parity. Is there any practical way to accomplish this?

Not with ZFS. There are filesystems on linux with built in ECC/ReedSolomon redundancy although I'm not sure any of them are production quality. For example: http://users.softlab.ntua.gr/~ttsiod/rsbep.html

 

[lazy7689]

Thanks for the quick responses, Relativistic.

Looks like I'll have to wait for Vail to be released.

 

[Relativistic]

I still think using multiple disks (you said you want to have to ability to add disks) without parity is a bad idea, Vail or not.

I agree that the upfront cost for a zfs array is higher since there is no ability to expand an already existing vdev, only append more vdevs to it. But it will pay off in the future.

 

[lazy7689]

I already have an off-site backup in place and I'm willing to risk the ~1-2 weeks worth of data (time between backups) than incur the additional cost of devoting drives to parity (and being required to purchase multiple drives at one time instead of taking advantage of decreases in pricing and increases in drive size) on top of the cost of the backup. As a result of having the backup and my tolerance of risk, protection for bitrot is my main concern (with driving pooling being my next issue).

 

[brutalizer]

ZFS always detects bit rot, even on a single drive. ZFS can not repair every problems with a single drive, since it needs to have a backup copy of every bit on another drive to be able to repair.

Alternatively, you could instruct ZFS to use only one drive, and spread the backup copy of every bit, on that single drive. This means your drive will get half the storage capacity. But in this case it suffices with only a single drive. It is as if you partition this drive into two parts, and use the parts as a mirror. If one bit goes down, ZFS just fetches the correct bit from the other mirror.

Alternatively, you could instruct ZFS to use only one drive, but spread three copies of every bit on that single disk. This means your drive will get one third of the storage capacity. To do shit you use the "copies=2" or "copies=3"

Every storage solution need to have correct bits somewhere else to be able to repair. It is not possible to use one single drive that repairs everything without having some safety redundancy.

Not with ZFS. There are filesystems on linux with built in ECC/ReedSolomon redundancy although I'm not sure any of them are production quality. For example: http://users.softlab.ntua.gr/~ttsiod/rsbep.html

I would not use this solution as Reed-Solomon does not suffice to repair all bit rot. Not even can Reed-Solomon even DETECT all errors. Here are research papers on this, and on the safety of ZFS:
http://hardforum.com/showpost.php?p=1036404173&postcount=73

 

[john4200]

I would not use this solution as Reed-Solomon does not suffice to repair all bit rot. Not even can Reed-Solomon even DETECT all errors.

No algorithm can detect ALL errors, even in theory. ZFS defaulted to fletcher2 for quite a while, but that was found to be broken, so now it is defaulting to fletcher4. But even that cannot guarantee to detect all errors.

Reed Solomon coding can detect and correct a lot of errors if you devote enough bits to the ECC code.

 

[brutalizer]

I know that. But ZFS does not rely on one single algorithm.

Why dont you read the research papers I linked too, instead?

 

[john4200]

I know that. But ZFS does not rely on one single algorithm.

Why don't you read the research papers I linked too, instead?

Why don't you read some more about ZFS, since you clearly do not understand how ZFS does checksums. It does indeed rely on a single algorithm. It was using fletcher2 for quite a while. Now it is fletcher4. Yes, it is user configurable, but whatever algorithm is used to generate the checksum is the only one available to detect corruption, obviously.

 

[brutalizer]

Why don't you read some more about ZFS, since you clearly do not understand how ZFS does checksums. It does indeed rely on a single algorithm. It was using fletcher2 for quite a while. Now it is fletcher4. Yes, it is user configurable, but whatever algorithm is used to generate the checksum is the only one available to detect corruption, obviously.

I suspect I know more about ZFS than you do.

fletcher2 is used to see if any bits have been altered in a data block, since the last read. The requirements are low here. fletcher2 is not cryptographically strong, that does not matter too much.

If you want to see if two data blocks are identical - then you can not use fletcher2. Because there is a very small probability that fletcher2 will say two data blocks are identical - even though they are not identical. But that is not the case here.

We want to see if two data blocks differs - not if they are identical. The requirements are much lower in this case. "Are there any altered bits since the last read?" has much lower requirements than "are these two data blocks identical, bit for bit?" This scenario, fletcher2 can do satisfactory. In other words, fletcher2 is probably safe to use, in this simple scenario. I see no reason to switch to fletcher4 in this scenario.

However, for data deduplication, fletcher2 is not safe to use because the requirements are much higher. Then we have to compare bit for bit, then fletcher2 or SHA256 is recommended. I would strongly advise against fletcher2 in that case.

 

[Relativistic]

I suspect I know more about ZFS than you do.

fletcher2 is used to see if any bits have been altered in a data block, since the last read. The requirements are low here. fletcher2 is not cryptographically strong, that does not matter too much.

If you want to see if two data blocks are identical - then you can not use fletcher2. Because there is a very small probability that fletcher2 will say two data blocks are identical - even though they are not identical. But that is not the case here.

We want to see if two data blocks differs - not if they are identical. The requirements are much lower in this case. "Are there any altered bits since the last read?" has much lower requirements than "are these two data blocks identical, bit for bit?" This scenario, fletcher2 can do satisfactory. In other words, fletcher2 is probably safe to use, in this simple scenario. I see no reason to switch to fletcher4 in this scenario.

However, for data deduplication, fletcher2 is not safe to use because the requirements are much higher. Then we have to compare bit for bit, then fletcher2 or SHA256 is recommended. I would strongly advise against fletcher2 in that case.

Fletcher2 has a 50% chance of missing 2 consecutive bit errors. Its a piece of poo. But what does that have to do with anything? You can't even set the dedup algo to fletcher2 in the current zfs build.

Are you a troll or just dense?

 

[vraa]

Fletcher2 has a 50% chance of missing 2 consecutive bit errors. Its a piece of poo. But what does that have to do with anything? You can't even set the dedup algo to fletcher2 in the current zfs build.

Are you a troll or just dense?

We are all trolls

I have a question for you - do you have any production environments with dedupe on?

We had multiple arrays with dedupe on and after a while those arrays with dedupe vs those without ended up much slower (this was on opensolaris b134 v24 i think zfs), I was told that unless you have major gobs of ram (32gb and higher) dedupe was probably not going to be cost effective in our situation

Since then I have stopped using dedupe and compression on my zpools

 

[john4200]

Relativistic, I think the answer to the question is, BOTH!

 

[brutalizer]

Fletcher2 has a 50% chance of missing 2 consecutive bit errors.

Ok, prove it.

You can't even set the dedup algo to fletcher2 in the current zfs build.

Again, dedup is another thing. Dedup has higher requirements than only detecting if a bit has been altered. Fletcher2 is only used to see if a bit has been altered. You do not need a cryptographically strong hash function to do that. Have you studied cryptography? Do you know when you need a cryptographically strong hash function, and when you do not need it?