Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #238492

Re: Disk for a small server

Show all headers | View raw

On 8/10/21 7:51 PM, Celejar wrote:
> On Tue, 10 Aug 2021 17:35:32 -0700
> David Christensen <dpchrist@holgerdanske.com> wrote:
> 
>> On 8/10/21 12:56 PM, Dan Ritter wrote:
>>> David Christensen wrote:
>>>> On 8/10/21 8:04 AM, Leandro Noferini wrote:
>>>>
>>>> https://wiki.debian.org/ZFS
> 
> ...
> 
>>>> - ECC memory is safer than non-ECC memory.
>>>
>>> This is true, but there is nothing that makes ZFS more dangerous
>>> than another filesystem using non-ECC memory.
>>
>>
>> I think the amount of danger depends upon how you do your risk
>> assessment math.  I find used entry-level server hardware with ECC
>> memory to be desirable for additional reasons.
> 
> Dan's point is that while ECC memory is indeed safer than non-ECC
> memory, this is true whether one is using ZFS or some other filesystem;
> furthermore, with or without ECC memory, there's no reason to believe
> that ZFS is less safe than the alternative.
> 
> See:
> 
> https://arstechnica.com/information-technology/2020/05/zfs-101-understanding-zfs-storage-and-performance/?comments=1&post=38877683
> https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/
> 
> So while ECC memory is always good, it's not a consideration when
> trying to choose between ZFS and other filesystems.


I see two sets of choices:

1.  Memory integrity:

     a.  No error checking or correcting -- non-ECC.

     b.  Error checking and correcting -- ECC.

2.  Operating system storage stack data integrity:

     a.  No data integrity -- md, LVM, ext*, FAT, NTFS.

     b.  Data integrity -- dm-integrity, btrfs, ZFS.


There are four combinations of the above.  I order them from highest 
risk (A) to lowest risk (D) as follows:

A.  Non-ECC memory (1a) and data integrity (2b)

B.  Non-ECC memory (1a) and no data integrity (2a)

C.  ECC memory (1b) and no data integrity (2a)

D.  ECC memory (1b) and data integrity (2b)


I have seen a few computers with failing non-ECC memory and no OS 
storage stack data integrity (case B).  It might take weeks or months to 
identify the problem.  If those computers had had OS storage stack data 
integrity with automatic correction (case A), the "scrub of death" is 
the logical outcome (failure modes and effects analysis); it's just a 
question of time.  Given the eventual catastrophic outcome (fault hazard 
analysis), I see a significant difference in risk between A and B.


I started buying ECC machines specifically for ZFS a few years ago (case 
D), and suffered through a rash of drive, rack, cable, and/or HBA 
failures.  Given RAID, ZFS snapshots, backups, etc.,, I replaced bad 
drives, fixed connections, resilvered, restored, verified, etc., with 
minimal loss.  If I had chosen md, LVM, and ext4 instead (case C), there 
would still be hardware checksums inside the drives, hardware checksums 
on the connections,  and memory checksums.  So, the risk difference C-D 
is less pronounced than A-B.


Holding the data integrity choice constant and comparing memory choices 
(cases A-D and cases B-C), I see more risk with non-ECC memory and less 
risk with ECC memory for both data integrity choices.


So, I do consider memory when choosing the storage stack.  Furthermore, 
my OS storage stack data integrity choice with non-ECC memory is the 
opposite of my choice with ECC memory.  My desktops and laptops have 
non-ECC and ext4 (case B).  My servers have ECC and ZFS (case D).


Therefore, my suggestion of ZFS on RPi contradicts my own practice.  :-/


David

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Disk for a small server Leandro Noferini <lnoferin@cybervalley.org> - 2021-08-10 17:20 +0200
  Re: Disk for a small server ghe2001 <ghe2001@protonmail.com> - 2021-08-10 19:10 +0200
    Re: Disk for a small server Leandro Noferini <leandro@cybervalley.org> - 2021-08-10 20:30 +0200
      Re: Disk for a small server ghe2001 <ghe2001@protonmail.com> - 2021-08-10 20:50 +0200
      Re: Disk for a small server rhkramer@gmail.com - 2021-08-10 21:10 +0200
        Re: Disk for a small server Leandro Noferini <lnoferin@cybervalley.org> - 2021-08-10 21:10 +0200
          Re: Disk for a small server Thomas Amm <debili@open-email.net> - 2021-08-10 22:40 +0200
      Re: Disk for a small server Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-11 01:00 +0200
        Re: Disk for a small server Leandro Noferini <leandro@cybervalley.org> - 2021-08-11 11:20 +0200
          Re: Disk for a small server Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-11 12:30 +0200
  Re: Disk for a small server David Christensen <dpchrist@holgerdanske.com> - 2021-08-10 21:50 +0200
    Re: Disk for a small server Dan Ritter <dsr@randomstring.org> - 2021-08-10 22:00 +0200
      Re: Disk for a small server David Christensen <dpchrist@holgerdanske.com> - 2021-08-11 02:40 +0200
        Re: Disk for a small server Celejar <celejar@gmail.com> - 2021-08-11 05:00 +0200
          Re: Disk for a small server David Christensen <dpchrist@holgerdanske.com> - 2021-08-11 12:00 +0200
            Re: Memory and other hardware safety issue regarding ZFS [was Disk  for a small server] Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-11 12:30 +0200
            Re: Disk for a small server Celejar <celejar@gmail.com> - 2021-08-11 16:10 +0200
              Re: Disk for a small server David Christensen <dpchrist@holgerdanske.com> - 2021-08-11 23:50 +0200
                Re: Disk for a small server Stefan Monnier <monnier@iro.umontreal.ca> - 2021-08-12 00:00 +0200
                Re: Disk for a small server <tomas@tuxteam.de> - 2021-08-12 08:50 +0200
    Re: Disk for a small server <tomas@tuxteam.de> - 2021-08-10 22:00 +0200
      Re: Disk for a small server David Christensen <dpchrist@holgerdanske.com> - 2021-08-11 03:00 +0200

csiph-web