4 ms·

There is also a linear degradation of metadata/blockinfo performance (in the order of the number of rewrites) due to the need to check multiple possible locatio

by paulmd 5y ago

There is also a linear degradation of metadata/blockinfo performance (in the order of the number of rewrites) due to the need to check multiple possible locations for the block pointer. In practice this probably just means more RAM utilization but... eh. Even as a home user, I've become convinced the juice is not worth the squeeze. For serious use, just buy four drives at a time and upgrade four drives at a time. That gives you 4-drive RAIDZ1 in one VDEV and if you want you can expand to a second VDEV or upgrade the capacity of the drives in your existing VDEV. If you don't want to do four drives at once, you can still use ZFS with 1 drive = 1 pool (or 2 mirrored drives = 1 pool for redundancy) and just manually distribute files over the volumes. No, it won't automatically do it like Unraid but perhaps you can layer unraid over the top somehow if you really insist (otherwise there's also solutions like git-annex). It still gets you far better data integrity guarantees and far better reliability than any available alternatives. Maybe it is just stockholm syndrome but do you really, really need to dynamically expand your array by an arbitrary number of disks that badly? There is ultimately no way around the reliability question so you can't expand forever and if you're serious about setting up a nice fileserver that'll be reliable for the long run, putting 4 drives in it isn't that bad. And ZFS is no worse than the alternatives on 1-drive or 2-drive scenarios in terms of reliability/expansion. Meanwhile ZFS is far far better than the alternatives (btrfs) in terms of data integrity and reliability. There is also the possibility of manually doing some weird shit like putting 2 partitions on each disk so you could move one member of the VDEV over to another disk if you expand, if you start with 2 disks with 2 partitions each then you could grow to 4 disks without issue, which would lower the increment even further.

WastingMyTime89 5y ago
> Meanwhile ZFS is far far better than the alternatives (btrfs) in terms of data integrity and reliability. No, it's not. Btrfs is nowadays perfectly reliable as long as you avoid the in development features which are all explicitly marked as in development and will warn you. That's why Facebook uses it in production. It also has some nice advantage for home use. Btrfs pools are a lot simpler to manage and have less quirks than ZFS. > Maybe it is just stockholm syndrome but do you really, really need to dynamically expand your array by an arbitrary number of disks that badly? There is ultimately no way around the reliability question so you can't expand forever and if you're serious about setting up a nice fileserver that'll be reliable for the long run, putting 4 drives in it isn't that bad. Btrfs will do that just fine for example. That's really a limitation of ZFS. I wish ZFS users would just stop FUDing about btrfs. Most of them haven't touched it for a decade and keep paroting the same old things.
- nix23 5y ago
  I used/use SLES for a long time, and there is a strong recommendation from SUSE itself how you should btrfs with SLES. -Just use it for the OS, XFS for data -Just use it in mirror configuration -Don't touch anything else -Make Snapshots and delete them is stable With those points, i too had never a problem.
  - WastingMyTime89 5y ago
    Novell controls the XFS development and Redhat has bought a competing technology. Obviously they are not going to push Btrfs. Its use amongst large companies speak for itself however. I see that tge ZFS fanboys are out in force however. I mean, people should be free to use a second class citizen zoth a terrible license and a pool gestion made for masochists if they want.
    - michaelmrose 5y ago
      Why is Novell's statement that BTRFS is only narrowly useful trivially ignored but large companies eg Facebook using it meant to be interpreted as positive proof while handily ignoring that Facebook is using it for ephemeral data.
      - nix23 5y ago
        >ignoring that Facebook is using it for ephemeral data What really?? That's hilarious!! Probably just because of zstd compression i would think.
    - nix23 5y ago
      >Novell controls the XFS development and Redhat has bought a competing technology. What? Are you trolling? Redhat is the biggest contributor to XFS > Silicon Graphics Red Hat https://en.wikipedia.org/wiki/XFS https://en.wikipedia.org/wiki/XFS >Its use amongst large companies speak for itself however. Tell me please? Facebook and.....? >second class citizen zoth a terrible license RHEL does not support btrfs anymore (since 2017) i wonder why is that...oh right RHEL is not a experimental distribution. I would say btrfs is not first class at all (ext4 and XFS is), i just wait until Linus and his Fedora create some entertaining emails.

by paulmd 5y ago

WastingMyTime89 5y ago

> Meanwhile ZFS is far far better than the alternatives (btrfs) in terms of data integrity and reliability. No, it's not. Btrfs is nowadays perfectly reliable as long as you avoid the in development features which are all explicitly marked as in development and will warn you. That's why Facebook uses it in production. It also has some nice advantage for home use. Btrfs pools are a lot simpler to manage and have less quirks than ZFS. > Maybe it is just stockholm syndrome but do you really, really need to dynamically expand your array by an arbitrary number of disks that badly? There is ultimately no way around the reliability question so you can't expand forever and if you're serious about setting up a nice fileserver that'll be reliable for the long run, putting 4 drives in it isn't that bad. Btrfs will do that just fine for example. That's really a limitation of ZFS. I wish ZFS users would just stop FUDing about btrfs. Most of them haven't touched it for a decade and keep paroting the same old things.

nix23 5y ago
I used/use SLES for a long time, and there is a strong recommendation from SUSE itself how you should btrfs with SLES. -Just use it for the OS, XFS for data -Just use it in mirror configuration -Don't touch anything else -Make Snapshots and delete them is stable With those points, i too had never a problem.
- WastingMyTime89 5y ago
  Novell controls the XFS development and Redhat has bought a competing technology. Obviously they are not going to push Btrfs. Its use amongst large companies speak for itself however. I see that tge ZFS fanboys are out in force however. I mean, people should be free to use a second class citizen zoth a terrible license and a pool gestion made for masochists if they want.
  - michaelmrose 5y ago
    Why is Novell's statement that BTRFS is only narrowly useful trivially ignored but large companies eg Facebook using it meant to be interpreted as positive proof while handily ignoring that Facebook is using it for ephemeral data.
    - nix23 5y ago
      >ignoring that Facebook is using it for ephemeral data What really?? That's hilarious!! Probably just because of zstd compression i would think.
  - nix23 5y ago
    >Novell controls the XFS development and Redhat has bought a competing technology. What? Are you trolling? Redhat is the biggest contributor to XFS > Silicon Graphics Red Hat https://en.wikipedia.org/wiki/XFS https://en.wikipedia.org/wiki/XFS >Its use amongst large companies speak for itself however. Tell me please? Facebook and.....? >second class citizen zoth a terrible license RHEL does not support btrfs anymore (since 2017) i wonder why is that...oh right RHEL is not a experimental distribution. I would say btrfs is not first class at all (ext4 and XFS is), i just wait until Linus and his Fedora create some entertaining emails.