Re: OpenMediaVault Server

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
+ signature.asc (application/pgp-signature)
+ (text/plain)
Delete this message
Reply to this message
Author: Ryan Petris via PLUG-discuss
Date:  
To: Main PLUG discussion list
CC: Ryan Petris
Subject: Re: OpenMediaVault Server
Given the performance level of hardware today, I don't believe parity
calculation is really causing much if any slowdown for parity raid,
just like encryption realistically does not caus any slowdown on modern
hardware.

As for what to use, I use OpenMediaVault at home and have a RAID6 6x8TB
array using native BTRFS. Yes, there's a big warning on the BTRFS wiki
about parity raid, however the issue is mitigated by using non-parity
raid for metadata, in which case I use raid1c3 when using raid6 for
data on BTRFS. This ensures the array can survive a 2 disk failure,
even if a disk fails after a poweroff.

The advantage of BTRFS over ZFS or regular mdadm raid is that you can
add/remove individual drives without having to re-create the entire
array, or change it to a different kind of raid should you want to. For
instance, lets say you started with RAID6 then decided you wanted
additional performance of RAID10 in exchange for losing some usable
space, you just rebalance the array to RAID10 and it will reconfigure
everything online. It may take a while, however it's still fault
tolerant while it's rebalancing. You can even pause/stop the
rebalancing, reboot, etc., while in progress and resume later when
needed; the existing data will remain at the original raid level while
any new data written will be at the new level.

If you actually read the wiki, it's apparent that the "write-hole"
they're concerned about is never going to be fixed, and in fact exists
in other raid implementations such as mdadm. The only reason there's a
big warning and is considered a bug is because their goal is for the
filesystem to be consistent all the time regardless of what happens.
Given the write hole, that's impossible, however using non-parity raid
for metadata works around this as the metadata will always be
consistent and can then be used to repair the affected data if the
parity information is incorrect.

On Fri, 2021-01-01 at 13:14 -0700, Stephen Partington via PLUG-discuss
wrote:
> If you are looking to just store data and use it for file access,
> Raid 5 should be valid. I would Use raid10 in cases where the disk
> activity would be database related or VM related. (Or just that much
> R/W IO where Raid 5 Parity calculations are killing you)
>
>
> On Fri, Jan 1, 2021 at 5:06 AM Phil Waclawski via PLUG-discuss
> <> wrote:
> > I really need a way to backup and keep track of all the media files
> > (photos, video etc) that I've created over the years.
> > I've been looking at FreeNAS, OpenMediaVault and others.
> >
> > Any suggestions on drives?  (thinking a RAID 10  of 4   8TB
> > drives)?
> > File Systems? (ext4 or ZFS or?)
> >
> > Any other advice would be appreciated. (hardware, software etc)
> > Phil W
> >
> > --
> > The Maricopa Community Colleges are now operating fully remotely.
> > We hope you are safe and healthy during this time. 
> > My in person and hybrid classes are all meeting at the regular
> > times via remote software. Lab and office hours as well. Please
> > check Canvas for the details and links, or email me with further
> > questions.
> > ---------------------------------------------------
> > PLUG-discuss mailing list -
> > To subscribe, unsubscribe, or to change your mail settings:
> > https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list -
> To subscribe, unsubscribe, or to change your mail settings:
> https://lists.phxlinux.org/mailman/listinfo/plug-discuss

---------------------------------------------------
PLUG-discuss mailing list -
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss