I’m new to stratis, so apologies if I bring up things that have been discussed elsewhere
previously. I don’t really understand the reluctance of RH to use zfs. Yes, it’s not
GPL’ed. But it is CDDL. And as long as you don’t try to compile it into a monolithic
kernel for distribution that would be fine. e.g.
But what I can’t understand (Even after reading the papers) is why attempt to use LVM and
xfs, which really don’t have the functionality I (Or anyone else that I can find) require,
and I see no chance for them ever having it, when there is a filesystem that does have the
features. And is gplv2’ed. e.g. advfs. Yes, it had its issues back in the 90’s. Yes, it’s
(currently) limited to 16TB files and filesystems. Yes it’s tied to True64. But would the
effort to complete (I have seen some attempts already) the port it to Linux, and extend
its capabilities be more than the effort required to get LVM2 & xfs to a position
where you could consider it a worth competitor for zfs?
No, I’m not asking for a change of direction here. That would be too much to hope for. I’d
just like to understand why existing filesystems were ruled out in favour of something
that I just can’t see working as seamlessly as I require in my day job.
The functionality I require? Something equivalent to solaris Alternate Boot Environments
aka ABE with zfs. Instant multi-level snapshot, instant (Via reboot) rollback. You can’t
create that with LVM. Heck, xfs can’t even shrink its filesystems. Sparse LV’s may hide
some of that. But not all. Snapshot and patch with rollback for existing enterprise
systems is a doddle with Solaris and zfs (Change pointer for active, reboot and done - and
the patched system is still there & available for diagnostics!). With Linux, not so
much (A poor alternative at best - And I hope my Solaris SME colleagues never read this,
they’ll give me stick for years). If i had a pound for every time LVM trashed a filesystem
for me with it’s snapshots, I’d be a rich man.
On 30 Jun 2018, at 20:40, Tao Effect <contact(a)taoeffect.com>
I've been researching ZFS and in the process stumbled upon Stratis and its Software
Design paper .
The conclusion reads:
> Based on looking at the existing available building blocks, the best option is to
build Stratis as a new project that initially makes use of XFS and device-mapper in its
implementation. In parallel, request enhancements to LVM2 to enable its substitution for
device-mapper when the enhancements are implemented. This lets Stratis proceed without
delay to a point where it can be placed in prospective users’ hands to start getting
feedback, and will allow Stratis to eventually use LVM2, and avoid duplicating
functionality that LVM2 already provides.
I must same that I am very dismayed and disappointed to read that LVM is being considered
at all, given the existence of ZFS, when the point of Stratis seems to be an extremely
convoluted way of trying to replicate the excellent design of ZFS without using ZFS
because of obscure licensing fears.
LVM is a usability nightmare compared to ZFS .
I think it is great that Stratis at least pushes the envelope in some way by choosing
Rust as its implementation language.
However, why should anyone be excited about the prospect of using a system that is
designed to be inferior to ZFS?
Why is all of this effort being poured into an inferior system design?
ZFS certainly has its problems (its installation is currently a nightmare thanks to lack
of distro support), but software architecture design and usability do not seem to be one
I wish Linux distributions had something like ZFS, whether that comes in the form of
Stratis or something else. ZFS has been around for 13 years and still nothing has come
close to beating it.
I urge this list to avoid expending effort on anything below the standard that ZFS has
Please do not email me anything that you are not comfortable also sharing with the NSA.
stratis-devel mailing list -- stratis-devel(a)lists.fedorahosted.org
To unsubscribe send an email to stratis-devel-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines