Dear list,
I've been researching ZFS and in the process stumbled upon Stratis and its Software Design paper [1].
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 [2].
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 of them.
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 set.
- Greg
[1] https://stratis-storage.github.io/StratisSoftwareDesign.pdf https://stratis-storage.github.io/StratisSoftwareDesign.pdf
[2] https://www.agileweboperations.com/zfs-vs-lvm-for-dummies https://www.agileweboperations.com/zfs-vs-lvm-for-dummies
-- Please do not email me anything that you are not comfortable also sharing with the NSA.
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. http://warpmech.com/?news=myth-busting-series-zfs-on-linux-has-license-probl... http://warpmech.com/?news=myth-busting-series-zfs-on-linux-has-license-problems and https://blog.ubuntu.com/2016/02/18/zfs-licensing-and-linux https://blog.ubuntu.com/2016/02/18/zfs-licensing-and-linux
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.
H
On 30 Jun 2018, at 20:40, Tao Effect contact@taoeffect.com wrote:
Dear list,
I've been researching ZFS and in the process stumbled upon Stratis and its Software Design paper [1].
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 [2].
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 of them.
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 set.
- Greg
[1] https://stratis-storage.github.io/StratisSoftwareDesign.pdf https://stratis-storage.github.io/StratisSoftwareDesign.pdf
[2] https://www.agileweboperations.com/zfs-vs-lvm-for-dummies https://www.agileweboperations.com/zfs-vs-lvm-for-dummies
-- Please do not email me anything that you are not comfortable also sharing with the NSA.
stratis-devel mailing list -- stratis-devel@lists.fedorahosted.org To unsubscribe send an email to stratis-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/stratis-devel@lists.fedorahost...
On 07/01/2018 05:26 AM, Hamish Marson wrote:
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. http://warpmech.com/?news=myth-busting-series-zfs-on-linux-has-license-probl... https://blog.ubuntu.com/2016/02/18/zfs-licensing-and-linux
This is a hard requirement for us, so ZFS is not an option.
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.
Stratis does not use LVM, it uses device-mapper, which LVM also uses. I believe we can eventually achieve many of the same use cases as ZFS, including the one you mention (upgrade with rollback). dm-thin has the capability to do this, and I think Stratis can make it as easy to use as ZFS, in the future.
I am not very familiar with advfs, thanks for mentioning it I'll try to learn more about it!
Regards -- Andy
Hi Andy, thanks fo rather ply.
On 2 Jul 2018, at 03:04, Andy Grover agrover@redhat.com wrote:
On 07/01/2018 05:26 AM, Hamish Marson wrote:
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. http://warpmech.com/?news=myth-busting-series-zfs-on-linux-has-license-probl... and https://blog.ubuntu.com/2016/02/18/zfs-licensing-and-linux
This is a hard requirement for us, so ZFS is not an option.
sigh… A monolithic kernel is a hard requirement? I didn’t know that. Disappointed, but I understand.
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.
Stratis does not use LVM, it uses device-mapper, which LVM also uses. I believe we can eventually achieve many of the same use cases as ZFS, including the one you mention (upgrade with rollback). dm-thin has the capability to do this, and I think Stratis can make it as easy to use as ZFS, in the future.
Hmm. Sorry, I didn’t appreciate the extra level in there properly. Would this include multiple versions of a filesystem? All utilising the same origin? e.g.
Start with a Base LV. Fork (snapshot) it so we have version0 and version1, both sharing the same blocks (Because they’re identical). Then we fork version0 again. To make version2 (Again, identical).
We alter version1 with a few changes (Probably Patches)… And alter version 2 with different ones.
Now we have 3 filesystems. version0, version1 and version2. All just slightly different form each other. We then fork version2. And make a few more changes to that. Now we have 4 filesystems. All slightly different from the base (version0) but importantly all sharing the same storage where they haven’t changed. And all able to be mounted and worked on simultaneously. With no corruptions because we ran out of blocks (Unless the VG runs out in which case I’d expect the filesystems to just refuse a write - just like a normally full filesystem now).
Is that level of snapshot going to be possible?
The bit I worry about is that LV snapshots at present use Copy On Write to the snapshot volume. Sometimes that’s an unacceptable performance hit (Especially for our LL guys). Whereas I believe zfs will just write the new block and adjust the pointers in the filesystem to use that leaving the old one in place where the other filesystems still use it. Can DM be convinced to doit that way when run-in with sparse LV’s?
I am not very familiar with advfs, thanks for mentioning it I'll try to learn more about it!
Ah. Cool. It’s the filesystem that Digital developed during the OSF/1 days (When it was called osf/1 before it was renamed to True64) back in the early ’90’s. It was kind of cool, although had a lot of bugs in the early days (I remember finding a few bad ones myself. Sometimes losing data which annoyed the users a lot).
regards Hamish
On 07/02/2018 12:11 AM, Hamish Marson wrote:
The bit I worry about is that LV snapshots at present use Copy On Write to the snapshot volume. Sometimes that’s an unacceptable performance hit (Especially for our LL guys). Whereas I believe zfs will just write the new block and adjust the pointers in the filesystem to use that leaving the old one in place where the other filesystems still use it. Can DM be convinced to doit that way when run-in with sparse LV’s?
Yes I believe so.
Just to be clear, there are two mechanisms in LVM to create snapshots. The newer one -- snapshots as part of dm-thin, "thin snapshots" -- there's no parent-child relationship between the original and the snapshot. Thin volumes have references to blocks, and multiple volumes can reference the same block. Making a snapshot just creates a new thin volume with references to its parent's blocks, and they can then of course then diverge and stop sharing blocks as changes are written to each. This works better for generational snapshots too (snaps of snaps). The snaps can exist even if the parent is deleted, etc.
"man 7 lvmthin" also has more info on thin provisioning and thin snaps.
Regards -- Andy
stratis-devel@lists.fedorahosted.org