Dr Bill C Riemers

In this case though, I verified the presense of the respective header files and typedef. So it likely a cmake/automake problem. Which I'm sure you already found.

For future reference, I had a very similar problem on my Mac for a bit new code I wrote on ARM I was trying to compile on my Mac. It turns out most of those modern C++ definitions are not in default include file set. My solution was just to install G++, and and the instructions for doing so to my README.md file, rather than to make my code explicitly typedef values like this.

I suspect BTRFS is probably a better solution for my needs, but I really wanted to try out this solution.

I ran this for the first time, and it took 7.5 hours to create 5.9 TB files. Both files have the same timestamp. Which has me fearing that means both parity files are being updated at the same time. In which case if I have a disk failure during that time window, neither parity file is valid... I'm actually impressed that it only took 7.5 hours, and a scrub on takes about 23 hours on the same set of drives. I am hoping on subsquent nights it takes advantage of the diff not to rebuild the full parity...

It has taken about a week to shift around the data to make this work. So far it looks good. The raid1c3 volume will also be useful to store configurations and such making it easier to recover. I probably won't go with the solution of extending the parity if it exceeds the 8:7 compression ratio, as that to me would indicate I should just buy a couple of 10 or 12 TB to be the parity drives.

It has taken about a week to shift around the data to make this work. So far it looks good. The raid1c volume will also be useful to store configurations and such making it easier to recover. I probably won't go with the solution of extending the parity if it exceeds the 8:7 compression ratio, as that to me would indicate I should just buy a couple of 10 or 12 TB to be the parity drives.

The pool idea probably won't work, because there will be no trigger for the expansion. So 4x7TB btrfs volumes for snapraid with the 2x8TB. Then the remainder 1TB drive and half the 4TB for triple backup brtfs RAID for very compressible files. If I use lvm for the party drives I can expand the parity drives if necessary. I have the raining 2TB on the 4TB drive and I am fairly certain I can scavenge a couple of 1TB drives for the other. So unless my compression ratio exceeds 10/7 I am good.

I realize this is an old discussion. But I stumbled across this because I have the same type of need. In my case the smapraid needs to be a live backup of NAS with 30 TB of stoage. i have 6x8TB+ a 4TB drive i can use for the backup. However, the NAS is using zsh compression. SMost of my files are non-compressible. But i do habe some colplete drive images and isofiles that atevessientially spars files. I Now the 4TB drive is very old, so i could use it for hail mary 3rd copy of things, but never with...