Given the shroud of mystic legalese incantations warding off the union of Linux and ZFS in many commercial products, Btrfs was, and still is, intended by many to fill the void. Btrfs has been slowly catching up to ZFS in features, but there’s still a long way to go. Btrfs still lacks
some relatively mundane features, such as disk encryption, but this is in many ways due to the complexity, and presumably because implementing such a feature could easily break backward compatibility.
Both Btrfs and ZFS allow for scripting many different operations, backups, replication, and customization among them. Both can be extremely hands off because they verify their consistency at all times, because of this, they are often referred to as ‘admin-less’.
But if Btrfs is so great, why does Red Hat want to nix it? Well, it comes down to a few key problems. The current state of storage management on Linux typically requires several layers of software (volume manager, RAID, filesystem, encryption, etc). While Btrfs combines many of these layers, it is still not yet a complete package. Another problem that is inherent to not only Btrfs, but ZFS as well, is that the command line utilities are designed for use by people. This means that the information returned by these commands cannot be used directly and must be parsed before anything meaningful can be done with it. Additionally, the output can change between versions of the utilities and system configurations making it all the more difficult to parse and use programmatically.
In Red Hat’s own words:
RHEL has gained many storage-related features over the years, but each of these features has required the user to manage the configuration of these features in a layered, additive manner. Genuinely new and useful features such as thin provisioning, RAID, and multipath are dependent on the user correctly configuring many different tools to achieve a complete result. Furthermore, since storage administration tools are focused on the command-line, higher-level management tools must each individually build upon the inherently risky proposition of treating the humanfocused syntax and output of command-line interface (CLI) tools as a stable programmatic API.Stratis Software Design - Red Hat
Red Hat has recently announced that Stratis is the solution that is being groomed for the fast track to storage reign. However, storage systems must be tried and true to see any significant adoption. Filesystem design is daunting enough without adding in all the layers that Red Hat insists on addressing in a single solution. So, how do you design a storage solution that’s as reputable as the veterans and also combines everything you need in a short amount of time? You don’t, you can’t, and you’d be a fool for trying, which is why Red Hat is doing just the opposite.
Stratis is not a new filesystem. It’s not a new volume manager. Stratis does not encrypt disks, assemble RAID arrays, or any of the like (at least not directly). Stratis is essentially a framework and API designed to allow high-level control or storage resources without the (direct) use of the command line tools. This is done by leveraging the flexible modularity of pre-existing Linux storage stacks.
It’s always been clear that Red Hat’s goal is enterprise appeal, and this new solution has the potential to simplify storage management across different platforms and storage media. There’s probably not much direct benefit to the average user or even the average Linux admin, but this technology could pave way for much more adaptive storage infrastructure in the cloud and hosting companies, meaning you may very well see faster and higher quality services as a result.
Clearly, this project is out of the scope of the average admin’s resources, and very few people actually run RHEL in small businesses or home environments. So, will Red Hat’s decisions impact the future of Btrfs (or ZFS) significantly? Let us know what you think about Stratis, Btrfs, ZFS, and any other filesystem you think is worth talking about in the comments below.
Comments
Post a Comment