3 ms·

Without the needed support from the kernel side Can you clarify what you mean by that?

mbreese 12y ago
Basically I mean integration with the kernel's code base and all of the testing that entails. After their initial development, file systems all end up migrating to the kernel's code base. So, I'm not thinking in terms of technical API support, but more development/testing/integration support.
- ryao 12y ago
  That is not a requirement. ZoL has the most sophisticated build system of any Linux kernel module in the world to enable it to live outside of the main tree. ZoL relies on autotools' API checks to do this. In addition, the project has an automated buildbot that helps us to detect regressions in pull requests before they are merged. It is similar in principle to how lustre filesystem development is done. Lustre is also (primarily) outside of the tree and lived entirely outside of the tree for years. That being said, being inside the kernel source tree is not necessarily a good thing. As I wrote in the blog post, other filesystems on Linux generally do not provide the latest code to older kernels, but ZoL provides the latest code to all supported kernels and distributions. This ranges from Linux 2.6.26.y to the 3.16.y in 0.6.3 and will include 3.17.y in 0.6.4. Something as important as a filesystem should be updated to fix bugs, even if the kernel proper cannot be. The inability of all Linux systems to update to the latest kernel is an issue that Linus Torvalds mentioned at LinuxCon North America 2014 and ZoL is one of the few filesystems that can deal with it on systems where it is deployed.
  - mbreese 12y ago
    You know... I hadn't given much thought to Lustre. And that is a very good comparison. Lustre is completely out of kernel (in terms of development), so it's not like you're the first to try this. I guess it really depends on where you want ZoL to be deployed. Lustre is typically deployed on HPC clusters and is managed by people who understand it, how to set it up, and how to manage it. It's not a trivial system to get working, and requires a pretty large budget. It just isn't setup on your typical server. Lustre also has a few big names behind it to provide development resources and support (Whamclound, now Intel). What is the target market for ZoL? Do you want it to work on servers? Clusters? Personal workstations? They are very different markets. I'm using ZFS right now for a single storage server that doesn't need to support a large cluster, so ZFS/NFS works great. But I'm using FreeBSD. For my Linux servers, I wouldn't think of using a filesystem that wasn't natively supported by Red Hat. I just don't want the management headache. I'm okay running a single FreeBSD box for my storage needs, but I'm fearful of what happens when I'd need to scale things out to multiple servers. I wish you luck, I really do. It seems like you're not going into this blind and you're making good decisions. But it will be an uphill battle and you'll always have that specter of Oracle looming over you. It doesn't matter if you're technically/legally right on the licensing front - you'll still have it looming over you until Larry signs off on it (like you said below). If you can get that sign off, then all bets are off, and you'd be golden!
justizin 12y ago
The previous poster clearly does not understand that ZFS on Linux is essentially a native port with very careful dancing around licensing borders.
- mbreese 12y ago
  The previous poster is well aware of what ZFS on Linux is. Licensing matters. It may not matter in terms of what I can do with my servers. I can compile ZFS and run it just fine on Linux. But you won't find Red Hat doing it. You won't find IBM doing it. Linus won't be adding it into the mainline tree anytime soon. This means that there may be "technical" solutions to getting ZFS running on Linux, but that also means that there will be artificial barriers in place that will make it more difficult to run, test, deploy, and support. These things matter. I might use ZFS for Linux on a personal workstation, but there is no way that I'd add it to a production cluster.
  - justizin 12y ago
    Right, but had you read the discussion this thread is about, you can see that Debian is working on a roadmap that includes binary drivers, shipped with the OS, available during the install. Linus has traditionally done a poor job of ensuring that filesystems will work well in production, ext4 being a _fantastic_ example of that. I appreciate the work he does, but I don't quite give a fuck if he is scanning the source for my filesystem. I've seen more ext4 filesystems go corrupt than all others combined. Red Hat and IBM can, equally, kiss my ass, I've never found either to be reliable. I don't see how DKMS is really an artificial barrier to run, test, deploy, and support something. It is, in fact, the opposite of a barrier - it's a tool.
    - mbreese 12y ago
      Debian is working on a roadmap that includes shipping source drivers to be slipstreamed in as dynamic modules. DKMS is a tool, but it's hardly the same as a good, in tree module. I remember having tons of issues with DKMS WiFi drivers back when I still ran a Linux laptop (10-ish years ago). If you get an upstream kernel upgrade and the ZFS DKMS module doesn't compile against it, you're screwed. Can you imagine trying to debug DKMS issues with your main filesystem? I hope you leave an ext2/3/4 volume around for booting and root. I'm glad that you feel like you can discount the work that IBM and Red Hat have done to advance Linux, but they've done a ton to make sure that Linux could take over data centers. Good to know... Thanks!

Basically I mean integration with the kernel's code base and all of the testing that entails. After their initial development, file systems all end up migrating to the kernel's code base. So, I'm not thinking in terms of technical API support, but more development/testing/integration support.

ryao 12y ago
That is not a requirement. ZoL has the most sophisticated build system of any Linux kernel module in the world to enable it to live outside of the main tree. ZoL relies on autotools' API checks to do this. In addition, the project has an automated buildbot that helps us to detect regressions in pull requests before they are merged. It is similar in principle to how lustre filesystem development is done. Lustre is also (primarily) outside of the tree and lived entirely outside of the tree for years. That being said, being inside the kernel source tree is not necessarily a good thing. As I wrote in the blog post, other filesystems on Linux generally do not provide the latest code to older kernels, but ZoL provides the latest code to all supported kernels and distributions. This ranges from Linux 2.6.26.y to the 3.16.y in 0.6.3 and will include 3.17.y in 0.6.4. Something as important as a filesystem should be updated to fix bugs, even if the kernel proper cannot be. The inability of all Linux systems to update to the latest kernel is an issue that Linus Torvalds mentioned at LinuxCon North America 2014 and ZoL is one of the few filesystems that can deal with it on systems where it is deployed.
- mbreese 12y ago
  You know... I hadn't given much thought to Lustre. And that is a very good comparison. Lustre is completely out of kernel (in terms of development), so it's not like you're the first to try this. I guess it really depends on where you want ZoL to be deployed. Lustre is typically deployed on HPC clusters and is managed by people who understand it, how to set it up, and how to manage it. It's not a trivial system to get working, and requires a pretty large budget. It just isn't setup on your typical server. Lustre also has a few big names behind it to provide development resources and support (Whamclound, now Intel). What is the target market for ZoL? Do you want it to work on servers? Clusters? Personal workstations? They are very different markets. I'm using ZFS right now for a single storage server that doesn't need to support a large cluster, so ZFS/NFS works great. But I'm using FreeBSD. For my Linux servers, I wouldn't think of using a filesystem that wasn't natively supported by Red Hat. I just don't want the management headache. I'm okay running a single FreeBSD box for my storage needs, but I'm fearful of what happens when I'd need to scale things out to multiple servers. I wish you luck, I really do. It seems like you're not going into this blind and you're making good decisions. But it will be an uphill battle and you'll always have that specter of Oracle looming over you. It doesn't matter if you're technically/legally right on the licensing front - you'll still have it looming over you until Larry signs off on it (like you said below). If you can get that sign off, then all bets are off, and you'd be golden!

justizin 12y ago

The previous poster clearly does not understand that ZFS on Linux is essentially a native port with very careful dancing around licensing borders.

mbreese 12y ago
The previous poster is well aware of what ZFS on Linux is. Licensing matters. It may not matter in terms of what I can do with my servers. I can compile ZFS and run it just fine on Linux. But you won't find Red Hat doing it. You won't find IBM doing it. Linus won't be adding it into the mainline tree anytime soon. This means that there may be "technical" solutions to getting ZFS running on Linux, but that also means that there will be artificial barriers in place that will make it more difficult to run, test, deploy, and support. These things matter. I might use ZFS for Linux on a personal workstation, but there is no way that I'd add it to a production cluster.
- justizin 12y ago
  Right, but had you read the discussion this thread is about, you can see that Debian is working on a roadmap that includes binary drivers, shipped with the OS, available during the install. Linus has traditionally done a poor job of ensuring that filesystems will work well in production, ext4 being a _fantastic_ example of that. I appreciate the work he does, but I don't quite give a fuck if he is scanning the source for my filesystem. I've seen more ext4 filesystems go corrupt than all others combined. Red Hat and IBM can, equally, kiss my ass, I've never found either to be reliable. I don't see how DKMS is really an artificial barrier to run, test, deploy, and support something. It is, in fact, the opposite of a barrier - it's a tool.
  - mbreese 12y ago
    Debian is working on a roadmap that includes shipping source drivers to be slipstreamed in as dynamic modules. DKMS is a tool, but it's hardly the same as a good, in tree module. I remember having tons of issues with DKMS WiFi drivers back when I still ran a Linux laptop (10-ish years ago). If you get an upstream kernel upgrade and the ZFS DKMS module doesn't compile against it, you're screwed. Can you imagine trying to debug DKMS issues with your main filesystem? I hope you leave an ext2/3/4 volume around for booting and root. I'm glad that you feel like you can discount the work that IBM and Red Hat have done to advance Linux, but they've done a ton to make sure that Linux could take over data centers. Good to know... Thanks!