Hacker News new | ask | show | jobs
by trumpeta 430 days ago
The reason I chose Synology over others was their SHR "filesystem", where you can continue adding heterogeneously sized disks after constructing the FS and it will make the most use possible out of the extra capacity in the new disks. When I researched it ZFS did not yet have the resizing feature merged, now it does, though I think it is still not able to use this extra space.

I'm wondering if anybody has any better recommendations given the requirement of being able to add storage capacity without having to completely recreate the FS.

7 comments

BTRFS doesn't care how big the disks are and you can just tell it to keep x number of copies of each data / metadata / system block and it will do the work of keeping your copies on different devices across the file system. Much like SHR, performance isn't linear with different sized devices, but it's super simple to setup and in tree where ZFS has a lot more complexity and is not baked into the kernel.

Snapshots are available, but a little more work to deal with since you have to learn about subvolumes. It's not that hard.

Edit: TIL, SHR is just mdadm + btrfs.

Any Linux with LVM. You don't need fancy proprietary OS for that.
To expand on this with an example. Adding a new device we'll call sdz to an existing Logical Volume Manager (LVM) Volume Group (VG) called "NAS" such that all the space on sdz is instantly available for adding to any Logical Volume (LV):

  pvcreate /dev/sdz
  vgextend NAS /dev/sdz
Now we want to add additional space to an existing LV "backup":

  lvextend --size +128G --resizefs NAS/backup
*note: --resizefs only works for file-systems supported by 'fsadmn' - its man-page says:

"fsadm utility checks or resizes the filesystem on a device (can be also dm-crypt encrypted device). It tries to use the same API for ext2, ext3, ext4, ReiserFS and XFS filesystem."

If using BTRFS inside the LV, and the LV "backup" is mounted at /srv/backup, tell it to use the additional space using:

  btrfs filesystem resize max /srv/backup
How are redundancy and drive failure handled? The only capacity mix-and-match scheme I have familiarity with is btrfs.
Synology SHR is btrfs (or ext4) on top of LVM and MD. MD is used for redundancy. LVM is used to aggregate multiple MD arrays into a volume group and to allow creating one or move volumes from that volume group.
Comment I responded to was using LVM on its own and I was wondering about durability. The docs seem to suggest LVM supports various software raid configurations but I'm not clear how that interacts with mixing and matching physical volumes of different sizes.
Same here, went with synology for SHR.

However I did notice that the performance was substantially worse when using heterogeneous drives, which makes SHR somewhat less valuable to me.

SHR is just Linux MDADM and LVM.
In addition to the alternatives already mentioned, I've been very happy with SnapRAID+MergerFS for a few years now. I don't have to worry about a magical black box as with btrfs or ZFS, I can expand the array with disks of any size, if one disk fails I only lose the data on that disk while the array remains usable, and it's dead simple to setup and maintain.

The only drawback, if I can call it that, is that syncs are done on-demand, so the data is technically unprotected between syncs. But for my use case this is acceptable, and I actually like the flexibility of being in control of when this is done. Automating that with a script would be trivial, in any case.

I was disappointed when I fully understood the limitations of SHR after purchasing my Synology box, and subsequently failed to install MergerFS on it. It's the only thing I miss about my old self managed server.
- mergerfs: https://github.com/trapexit/mergerfs - snapraid

Not used either but these were 2 options that came up when I was researching few years ago.

I'm in exactly same situation myself.
Windows storage spaces
It's all fun and games until your volume shows up as RAW and you're dead in the water.
I don’t think that is comparable with a good NAS.
NAS? No, but SAN or DAS, yes. It provides similar features, plus any bog standard x86 application you wish to run.
Why not?