Dr Bill C Riemers

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...

Years ago, AT&T sold DjVu to LizardTech. Inc. That company then owned two different imaging technologies. DjVu and MrSID. MrSID was mainly used for maps, as it could do unlimited map sizes both in lossless and lossy formats. DjVu was used for documents, as it had multiple layers and could store documents far more efficiently. One of the first things the developers did is try DjVu's image format as a replacement for MrSID, and tried MrSID's imaging format as a replacement for DjVu's background image...

You can consider this abandoned software. if i were to do anything with this it would be to rewrite something that uses an off the shelve xml library. This tool was never intended as a long term solution. Just more a proof of concept that met immediate needs. But I would not actually do the rewrite because I have no use for it. I also have no test bed to assure quality, and i have no evidence anyone else needs this updated badly enough to help support the effort it would take to ensure quality.