We all stopped using UNIX long ago, it's GNU/Linux now and it's only somewhat inspired by UNIX. What the UNIX people did 30 years ago is interesting from a historical perspective, but is not in any way the only right way to do things. I say did because that's now even how modern unices work. Solaris has for example been running on SMF since 2005 and they are doing just fine.
I suffered through having to edit/modify rc.local on 500 BSDish systems back in the day & welcomed SysV. A few years ago, I switched from Solaris 8 to 10 with SMF. Once it stabilized, it was nice enough for starting/stoping. I never liked the XML for configuration instead of the traditional plain text files in/etc I could sun sed -i -e on. I liked how I could still put stuff in/etc/init.d as well.
Systemd has been much easier to pick up and less problematic then SMF in Solaris 10.3 and earlier. I haven''t had to deal with many of the other issues people have been mentioning yet though
Typically you'd layer raid, then LVM, then the filesystem. ZFS tries to be all three. It's raid, and it's a volume manager, and it's a filesystem. There are some benefits to integration, and some drawbacks. With the raid>lvm>filesystem approach, it's trivial to add dm-cache, bcache, iscsi, or any other piece of storage technology.
ZFS can have things added on top just as trivially. I've never done smb in ZFS, I used Samba. On solaris, I did NFS with ZFS, but on Linux, I've kept it in/etc/exports.
With RAID+LVM+filesystem+network share, I need to unshare, umount. The resize LVM, resize the filesystem partition (if it is allowed), mount and export. With ZFS I do zfs set quota= zpool/directory. On the fly with no downtime. That alone is worth the difference.
ZFS does compression also. And you can toggle back & forth while running. zfs compression=on zpool/directory and every new write is compressed. compression=off and new items are not compressed.
ZFS also does checksums to verify the data. If you have a dodgy sata cable or controller firmware that corrupts your data, it will be detected. If ZFS is doing RAID, it has a 2nd copy of that data and can self correct. If it doesn't have a 2nd copy, it will shut the filesystem down so nothing else gets corrupted. You can't do that with hardware RAID.
With ZFS, anything you want to add has to be specifically supported within ZFS.
Not true at all.
The Unix tradition is small, single purpose tools that do one thing well. Witness sort, grep, wc, etc. Want to count the log entries that mention Slashdot? You don't need a special tool for that, just grep slashdot | wc -l . Tools like mdadm and lvm are building blocks that can be combined to suit your need, the Unix way. ZFS is a big monolithic package that does everything, much like Microsoft Word or Outlook. ZFS is more in the Microsoft tradition.
Some of the things that ZFS does would be difficult if it wasn't the whole system. Newer systems like btrfs and ceph take a similar approach.
Slashdot Mirror
We all stopped using UNIX long ago, it's GNU/Linux now and it's only somewhat inspired by UNIX. What the UNIX people did 30 years ago is interesting from a historical perspective, but is not in any way the only right way to do things. I say did because that's now even how modern unices work. Solaris has for example been running on SMF since 2005 and they are doing just fine.
I suffered through having to edit/modify rc.local on 500 BSDish systems back in the day & welcomed SysV. A few years ago, I switched from Solaris 8 to 10 with SMF. Once it stabilized, it was nice enough for starting/stoping. I never liked the XML for configuration instead of the traditional plain text files in /etc I could sun sed -i -e on. I liked how I could still put stuff in /etc/init.d as well.
Systemd has been much easier to pick up and less problematic then SMF in Solaris 10.3 and earlier. I haven''t had to deal with many of the other issues people have been mentioning yet though
> ZFS is a layer below LVM.
Typically you'd layer raid, then LVM, then the filesystem. ZFS tries to be all three. It's raid, and it's a volume manager, and it's a filesystem. There are some benefits to integration, and some drawbacks. With the raid>lvm>filesystem approach, it's trivial to add dm-cache, bcache, iscsi, or any other piece of storage technology.
ZFS can have things added on top just as trivially. I've never done smb in ZFS, I used Samba. On solaris, I did NFS with ZFS, but on Linux, I've kept it in /etc/exports.
With RAID+LVM+filesystem+network share, I need to unshare, umount. The resize LVM, resize the filesystem partition (if it is allowed), mount and export. With ZFS I do zfs set quota= zpool/directory. On the fly with no downtime. That alone is worth the difference.
ZFS does compression also. And you can toggle back & forth while running. zfs compression=on zpool/directory and every new write is compressed. compression=off and new items are not compressed.
ZFS also does checksums to verify the data. If you have a dodgy sata cable or controller firmware that corrupts your data, it will be detected. If ZFS is doing RAID, it has a 2nd copy of that data and can self correct. If it doesn't have a 2nd copy, it will shut the filesystem down so nothing else gets corrupted. You can't do that with hardware RAID.
With ZFS, anything you want to add has to be specifically supported within ZFS.
Not true at all.
The Unix tradition is small, single purpose tools that do one thing well. Witness sort, grep, wc, etc. Want to count the log entries that mention Slashdot? You don't need a special tool for that, just grep slashdot | wc -l . Tools like mdadm and lvm are building blocks that can be combined to suit your need, the Unix way. ZFS is a big monolithic package that does everything, much like Microsoft Word or Outlook. ZFS is more in the Microsoft tradition.
Some of the things that ZFS does would be difficult if it wasn't the whole system. Newer systems like btrfs and ceph take a similar approach.