So, my understanding of SAS and SATA compatibility thusfar has been that you can go from SAS to SATA, but never back. However, I’ve noticed a lot of SATA backplanes, that are essentially just SATA data passthrough and power pooling, claim to be SAS compatible.
If I have a SAS HBA with SATA physical outputs, can I just individually plug those into the data side of a backplane, plug in some SAS connectors, and expect that to work just fine?
SATA, SAS and U.2 all use the same physical connector, but different subsets of contacts on that connector. I had found a drawing outlining the various subsets of contacts, but cannot find it anymore. I still have to find a backplane that enables all 3 subsets, practically all are SATA/SAS, U.2 backplanes are rather rare.
As far as data goes, my understanding is indeed that a SAS to SATA adapter cable will work on a SAS-compatible backplane. I haven’t tried it yet (due to lack of said backplane) so so far it’s just hypothetical to me.
Do you have some photos/part links of the card and cables show what you’re trying to do? I don’t entirely follow what you described.
https://www.aliexpress.com/item/1005005668144562.html
Amazon reviews seem to also suggest the enclosure should work fine. The card was preflashed to IT mode, but LSI SAS HBAs are cheap.
The last-linked one plus some cables hanging out the back of a case is probably the cheapest solution, so if that works fine I’ll probably do that. The entire point was to get 3TB SAS drives cheaper per TB than tape, and to sit them on a shelf for cold storage.
On that note, I wonder if there’s something that can store enough parity on-disk to reconstruct in case of bitrot. Not worried about a drive dying on the cold shelf as much as flipped bits.
There is: plain ol’ RAID6. Dual disk parity distributed across all disks. ZFS uses a dedicated disk (or disks) for parity so loose that disk and you’re screwed if another disk in the pool has issues too. RAID6 can hold up to 32 drives. Preferably equal size, otherwise the array size reflects the smallest disk size it contains (i.e. a 4 drive RAID6 containing 3x 20TB and one 18TB drive will have 2x18TB storage capacity and also 2x18TB redundancy. The remaining 3x2 TB on the larger disks are available for other purposes though)
huh?
Yeah, this is extremely untrue. From the openzfs docs:
Data and parity is striped across all disks within a raidz group.
For a single drive, zfs can store multiple copies so that a flipped bit can be repaired: zfs set copies=[n] pool/dataset.
So, RAIDZ is just RAID6? So, what’s the use of RAIDZ over RAID6 then?
ZFS has a benefit over standard raid, because it had checksumming, so can detect bitbrot. Not all raid systems have this, and the ones that do, might only do scheduled patrol reads, not full scrubs to the same level. edit: see the next post
Usually the terminology patrol read only means that the disks are being scanned for bad sectors and disk health, not parity data (which is what you are implying, I thought I’d just spell it out for ppl).
To detect and correct bitrot RAID6 needs to perform a scrub, just as ZFS would. If a ZFS vdev isn’t ever scrubbed it can develop uncorrectable bitrot if bad enough, the only advantage it has over RAID6 in this regard is that as ZFS trys to serve up the data it will try to detect and correct bitrot, but only for the files it is active reading, not the ones “at rest” (which can corrupt away if not scrubbed).
Scrub time can also vary greatly between an “equivalent” ZFS vdev to RAID6 volume:
if little data is on the volume, ZFS can complete a scrub much faster than RAID6
if both volumes are filled up, RAID 6 will scrub faster
if the ZFS volume is fragmented (and there is not easy way to defragment them), ZFS can be significantly slower to scrub than a RAID6 volume.
2 Likes
Isn’t this just multiple copies of metadata?
Moreso looking at an efficient way to store and reconstruct data, similar to using multiple disks. I could connect 4 disks at a time, but if one of them fails, it would require a full resilvering to not be at risk, which means more stress on the drive, and since they’re old and used Constellation ES.2 drives, I’m not keen on them serving long work hours. Since the drives are intended to be cold(literally off) 99.% of the time, it seems very inefficient to use Raid5/6.
The only thing I can think of off the top of my head involves multipartitioning and snapraid, but that makes data management a nightmare, adds overhead of partition metadata, and increases the number of bits per drive wherein a flip could result in more difficult data loss.
Less RaidZ, more ECC for your harddrive, similar to what CDs did. I’m not sure ZFS or BTRFS support this, what I’ve read over the years seems to suggest that you either need to store multiple copies of the complete data, or that it only applies to metadata.
Something like every 8 Xbytes, store 2 parity Xbytes that can be used to correct any two of the previous 8 Xbytes.
No. This is multiple copies of data (for whatever dataset(s) you’ve set to copies=n), written to different parts of the disk. ZFS already defaults to 2 copies of metadata. Honestly if you don’t want to use mirrors or parity based raid this is probably the best you can do, especially since you can determine on a dataset level rather than the drive level which files to keep multiple copies of.
If you really want it to be based on parity calculations rather than simply additional copies of the drive’s data, you could divide the drive into 4-5 partitions and make a raidz vdev out of those partitions. Short of that though, I’m unaware of any filesystem that does what you’re asking for—it’s a design that’s built for a failure mode that is less likely than the entire drive failing, in which case all the data on that drive is completely hosed regardless of how much parity data you’ve got on it.
1 Like
I’m just going to leave this here because it is really easy to misunderstand what copies=n can do for you:
2 Likes
I made a script for tarring and feathering some data, and tricking snapraid into creating parity for it. 
Sounds interesting–mind sharing what you did?
it’s not interesting at all really
#!/bin/bash
SRC=$1
DST=$2
tar -cvf - $SRC | split -dn 10 -a 1 - $DST/N
echo "parity $DST/snapraid.parity" >$DST/snapraid.conf
for NUM in {0..9}
do
btrfs subvolume create $DST/$NUM
mv $DST/N$NUM $DST/$NUM/N$NUM
echo "content $DST/$NUM/$NUM.content" >>$DST/snapraid.conf
echo "data d$NUM $DST/$NUM/" >>$DST/snapraid.conf
done
snapraid sync -c $DST/snapraid.conf
snapraid check -c $DST/snapraid.conf
For tape storage, it may essentially require tarring the resulting files, and a tape cut on the edge of one of the files could make the next file unreadable. 2 parity would probably solve this, though.
For reconstruction, snapraid fix -c *$DST*/snapraid.conf and then cat {0/n1,1/n1,2/n2,3/n3,4/n4,5/n5,6/n6,7/n7,8/n8,9/n9} > file.tar and then untar the files however you please.
Should also work well to provide some bitrot protection for CD, DVD, or BD. But, for storage efficiency, it may not be the best.
1 Like
This topic was automatically closed 273 days after the last reply. New replies are no longer allowed.