Hi Andy, thanks fo rather ply.
On 2 Jul 2018, at 03:04, Andy Grover <agrover(a)redhat.com>
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.
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
> 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
We alter version1 with a few changes (Probably Patches)… And alter version 2 with
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).