Anyone an expert in Synology here?
Synology's Hybrid Raid (SHR) is a funky little system, especially since it's built on standard Linux tools.
What I'm wondering though, is how data is distributed when you change the disks in the system.
Imagine I have 2x1TB drives and 2x4TB drives in a system.
- First it creates a 4x1TB "chunk" which is essentially RAID5. (3TB available)
- Next it creates a 2x3TB chunk which acts like RAID1 (although internally may be calculated like a RAID5 parity.) (3TB available from this)
Now let's say I replace those two 1TB drives with 4TBs (safely, preserving data, etc.), and tell SHR to expand to use the new drives. I can see a number of scenarios from this point:
- It mirrors the two new blocks into another 3TB chunk, giving me 9TB total. (3 from RAID5, 3 from first mirror pair, 3 from second mirror pair)
- It expands the 3TB mirror into a second RAID5 group, giving 12TB total. (3 initial plus 9 in the second group)
- It does the same thing and also rewrites the data on the (former) 3TB mirror pair to be striped across all four disks
- It expands the 3TB mirror to RAID5, *and merges it with the original 3TB RAID group, giving a single 12TB RAID5.
- Again it does the same thing but with rewriting of the data that was formerly just mirrored.
This isn't likely to be a huge deal, but I'd like to know how it works under the covers.
I don't have a Synology, but I implemented SHR manually using mdadm and LVM. If you have a RAID 1 array you can just add disks to it and "upgrade" it to the next tier of your choice. So with 3 disks you could just go to RAID 5 and that chunk would now become RAID 5.
It wouldn't be merged with any additional chunks directly. Rather, you'd use LVM to create a volume group with each chunk added (each chunk world be formatted into a PV). From that you would carve out your volumes and then your file systems on top of that.
This is a pretty simple layout and I imagine Synology is pretty close to this.
The best way, I found to do this is to actually first partition your drives into 2-4TB chunks. Each of these partitions is then added to a RAID array, minimizing waste if you have mixed size drives. e.g. with three disks the first partitions are grouped into one raid array (chunk) and then the second partition of each disk is grouped into the next array, etc.
So, in your case, I suspect the Synology created a 1TB partition on each of your 1TB drives. If you replace 2 of those, Synology would create 1TB partitions on the new drives that match the existing raw disk size. It would then create a new RAID 1 array using the 3tb of additional space that's sitting on new 3tb partitions. LVM would then add this chunk to your volume(s).
Of course, that's just my guess based on research I did a while ago to build my own array. Check out the Synology RAID calculator. It'll give you some ideas about this, too.
Well, I've found some of the answer.
/volume1 is a single LV on a single VG - no surprise there. There are two PVs comprising it, each of which is a RAID5 group across an extended partition on the disks.
pv0 is /dev/sd[abcd]5 and pv1 is /dev/sd[abcd]6
Now what I find most interesting right now is that SHR supposedly required btrfs to operate - and yet, /volume01 is an ext4 filesystem.
Part of me would like to convert to btrfs, but I'd need a spare 10TB of storage just to back up to, before starting down that odyssey.
More digging, more questions.
I'm not sure why SHR would require any file system, it's an abstraction that sits below that layer.
The filesystem is stored on the volume(s) in the storage pool. Its advisible to create a seperate smaller volume for the packages because if a volume becomes corrupted you cant use things like active backup. It can happen because ive just went through that with my ds1821÷. Data was fine but the volume was unrecoverable and readonly. SHR is great but you need to start with the smallest drives as you can't add a 10tb drive and then a smaller one.