hw writes:

On Wed, 2022-11-09 at 19:17 +0100, Linux-Fan wrote:
> hw writes:
> > On Wed, 2022-11-09 at 14:29 +0100, didier gaumet wrote:
> > > Le 09/11/2022 à 12:41, hw a écrit :

[...]

> > I'd
> > have to use mdadm to create a RAID5 (or use the hardware RAID but that > > isn't
>
> AFAIK BTRFS also includes some integrated RAID support such that you do > not necessarily need to pair it with mdadm.

Yes, but RAID56 is broken in btrfs.

> It is advised against using for RAID 
> 5 or 6 even in most recent Linux kernels, though:
>
> 
https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices

Yes, that's why I would have to use btrfs on mdadm when I want to make a RAID5.
That kinda sucks.

> RAID 5 and 6 have their own issues you should be aware of even when > running 
> them with the time-proven and reliable mdadm stack. You can find a lot of 
> interesting results by searching for “RAID5 considered harmful” online. > This  > one is the classic that does not seem to make it to the top results, > though:

Hm, really? The only time that RAID5 gave me trouble was when the hardware

[...]

I have never used RAID5 so how would I know :)

I think the arguments of the RAID5/6 critics summarized were as follows:

* Running in a RAID level that is 5 or 6 degrades performance while
  a disk is offline significantly. RAID 10 keeps most of its speed and
  RAID 1 only degrades slightly for most use cases.

* During restore, RAID5 and 6 are known to degrade performance more compared
  to restoring one of the other RAID levels.

* Disk space has become so cheap that the savings of RAID5 may
  no longer rectify the performance and reliability degradation
  compared to RAID1 or 10.

All of these arguments come from a “server” point of view where it is assumed that

(1) You win something by running the server so you can actually
    tell that there is an economic value in it. This allows for
    arguments like “storage is cheap” which may not be the case at
    all if you are using up some thightly limited private budget.

(2) Uptime and delivering the service is paramount. Hence there
    are some considerations regarding the online performance of
    the server while the RAID is degraded and while it is restoring.
    If you are fine to take your machine offline or accept degraded
    performance for prolonged times then this does not apply of
    course. If you do not value the uptime making actual (even
    scheduled) copies of the data may be recommendable over
    using a RAID because such schemes may (among other advantages)
    protect you from accidental file deletions, too.

Also note that in today's computing landscape, not all unwanted file deletions are accidental. With the advent of “crypto trojans” adversaries exist that actually try to encrypt or delete your data to extort a ransom.

More than one disk can fail? Sure can, and it's one of the reasons why I make
backups.

You also have to consider costs. How much do you want to spend on storage and and on backups? And do you want make yourself crazy worrying about your data?

I am pretty sure that if I separate my PC into GPU, CPU, RAM and Storage, I spent most on storage actually. Well established schemes of redundancy and backups make me worry less about my data.

I still worry enough about backups to have written my own software:
https://masysma.net/32/jmbb.xhtml
and that I am also evaluating new developments in that area to probably replace my self-written program by a more reliable (because used by more people!) alternative:
https://masysma.net/37/backup_tests_borg_bupstash_kopia.xhtml

> https://www.baarf.dk/BAARF/RAID5_versus_RAID10.txt
>
> If you want to go with mdadm (irrespective of RAID level), you might also 
> consider running ext4 and trade the complexity and features of the > advanced file systems for a good combination of stability and support.

Is anyone still using ext4? I'm not saying it's bad or anything, it only seems that it has gone out of fashion.

IIRC its still Debian's default. Its my file system of choice unless I have very specific reasons against it. I have never seen it fail outside of hardware issues. Performance of ext4 is quite acceptable out of the box. E.g. it seems to be slightly faster than ZFS for my use cases. Almost every Linux live system can read it. There are no problematic licensing or stability issues whatsoever. By its popularity its probably one of the most widely-deployed Linux file systems which may enhance the chance that whatever problem you incur with ext4 someone else has had before...

I'm considering using snapshots.  Ext4 didn't have those last time I checked.

Ext4 still does not offer snapshots. The traditional way to do snapshots outside of fancy BTRFS and ZFS file systems is to add LVM to the equation although I do not have any useful experience with that. Specifically, I am not using snapshots at all so far, besides them being readily available on ZFS :)

HTH and YMMV
Linux-Fan

öö

Attachment: pgpiErtjPQ_tY.pgp
Description: PGP signature

Reply via email to