Maybe not yet if this about vengeance being served cold for having put ZFS in a bad light after losing data, twice, to gross mismanagement.
Back to the popcorn bucket then… 
You know, this is precisely the kind of issue that bit Billet Labs in the butt when LTT didn’t read the manual, used their heat sink incorrectly, then complained about crappy results. Even better, auctioned off said loaned heat sink without permission afterwards.
So I don’t have a lot of faith in anything LTT touches even if the intention is good and the people doing the work are more focused, talented, managed than Linus. Writing middleware is not simple and it takes a well managed team quite some time to recreate that which iXsystems has been working on for years.
I agree that in practice importing a pool should work across many a system. However, I also don’t put it beyond Linus and & co to make ZFS feature changes that are only native to their implementation. Maybe I’m too paranoid.
I don’t get LTTs or iXsystems angle in all this… nor the association that iXsystems seems to have repeatedly sought with LTT (see fawning posts like this one or this one).
Making a more accessible, simpler version of TrueNAS for the masses is actually a monumental undertaking, see how much time, resources, etc. Apple poured into the original Mac OS to make it “simple” and accessible. The underlying software has to become a lot ‘smarter’ to prevent users from making bone-headed decisions, errors have to be displayed with understandable remedy suggestions, etc.
This is a far cry from the present middle-ware state with its almost limitless bone-head potential and cryptic middle-ware error messages.
2 Likes
You do realize iX sells special glasses to fix this? Maybe next time research something before you comment on it?
4 Likes
Linus being involved in any way (even if just financing) is enough basis for concern; he seems to have a nearly-unlimited capacity shooting himself in the foot. I don’t think it’s likely he’s going to mess with the ZFS code, but I wouldn’t put it past him.
Agreed–the only sensible response on iX’ part would be a very loud, and very clear, “we have nothing to do with this moron.”
But as much as I’ve contributed to it, the purpose of this topic wasn’t really to bash Linus, but more to discuss this HexOS thing. And we’ve learned a few things:
- iX knows about it, and appears unwilling to discuss what they know about it.
- Thus they’ve presumably authorized splashing the TrueNAS branding/logo all over the HexOS web site.
- It isn’t a fork of any version of TrueNAS.
- iX gets touchy when the subject of forking TrueNAS is mentioned–Morgan, you really didn’t need to change the title of this topic.
- “Current and future (Docker) Apps work,” whatever this means
- “It’s not for people who understand how to administer a TrueNAS system.”
So, a kind of third-party, but officially-endorsed, TrueNAS for Dummies? I guess this makes sense, except for the part about it being third-party.
2 Likes
At the risk of veering away from the thread topic, i think this comment needs an answer.
- Container networking
- Not having to rely on the docker image for certain things (ffmpeg + Nextcloud)
- Not having to rely on a docker image to be updated
- Being able to configure an entire jail exactly how I want, and not rely on the container creators “good intentions”
- One central repo as opposed to many different repos to choose from
I don’t know if you will view these things as superior or not, but I do, and they are the reason I continue to use and support BSD.
We could also make the claim that Linux is far superior to BSD in many things like
- Popularity
- App availability
- Everyone is using it, so everything has a docker image
I made the comment I made based on my experience and knowledge, so it is a personal view. Perhaps i should have said “in my opinion” but I figured it would be understood as such.
2 Likes
If so, that means that support to the target users will NOT officially land here. Which, I’d say, is rather a good thing. Let LTT own it.
1 Like
Remember to criticize ideas, not people. Please avoid:
- Name-calling
- Ad hominem attacks
5 Likes
The aim seems to be a slimmed down TrueNAS with built in SMB, a VPN, etc. as a direct competitor to Open Media Vault but with a ZFS / TrueNAS Scale back end. For $250k, this is a impressive amount of work, if it’s more than a couple of manufactured screen shots.
Radically simplifying the user experience in HexOS will require a lot more work under the hood though, i.e. implementation of best practices, simplified ACLs, and so on. Never mind how to get Docker and like images to “just work”. If they can pull it off (especially the networking, security, etc.), it would be a boon to iXsystems since iXsystems has struggled with figuring out how to implement Docker/Kubernetes/etc. on a wide scale without a billion tech support tickets here and in Jira.
However, a simple UI that can do complex things combined with the high likelihood of folk attempting to do server work with non-server components (SMR, realtek, etc.) and the stage is set for a lot of unhappy user experiences. Or, how do you explain Snapshots and the room they take without getting far away from simplicity?
I’ll be happy if I’m wrong but I don’t see how this project is going to work as intended unless a heck of a lot more money is invested than 250K. Without a clear funding path (subscription?) I don’t see how this project can sustain itself in the long run, even if iXsystems is partnering with them.
2 Likes
Yep, permissions really are an Achilles’ Heel. Coming up with defaults that are at the same time reasonably-secure and usable for a n00b is going to be tricky.
That’s how I headlined this thread, but it’s not really clear to me if this project really belongs to LTT, or if Linux just decided to invest in something they were already working on (and for which they had other funding). That could change, well, a lot of things.
But why? OMV already does ZFS, doesn’t it? What’s this going to bring to the party? “A much better UX for n00bs” is a valid answer if it actually does so, which I suppose is TBD.
I’m a good capitalist, so I’m all for increased competition–it’s good for everyone, especially the users, that there be a good field of competing products, each driving its competition to do better. But in that competition, a successful product is going to have to bring something unique to the table, and I’m not sure “a better UI” will be compelling. Ah, but what if there’s a direct upgrade path to TrueNAS? Download a config file from HexOS, install SCALE, upload that config, and now you have everything you had before, but now in “Advanced Mode”? That might go somewhere…
But still, the story doesn’t make a lot of sense to me. Either of these scenarios would:
- iX decides they need a “TrueNAS for Dummies” product and either create it themselves or hire it out, calling it, I don’t know, maybe half-truthNAS.
- Former unRAID devs don’t like where that product is going (maybe with recent licensing changes?), leave the company and create a “better” (in whatever way they believe it had been lacking) unRAID.
But what’s going on here seems like some weird hybrid of the two, and doesn’t seem to make a lot of sense.
2 Likes
He’s fooling around. His target audience appreciates it.
You don’t need to and that’s completely fine too.
Having said that, literally sawing motherboards apart as a way to modify them is an “art” practiced in some fringe markets…
2 Likes
OMV has an “extra” to install ZFS. Somewhat scarred by multiple attempts to install Docker in OMV[1], I did not dare try it.
I would not blindly assume that ZFS is well-integrated with OMV and easy to use because it is listed somewhere in the docs…
Instructions are NOT in fully logical order and everything has to be patiently validated at each step under penalty of ending up in an undefined state which might no longer work after a reboot. But, at the third attempt, I eventually managed to have it running reliably starting from scratch.
Lessons: #1 docker-compose is A LOT easier to use than k3s under SCALE.
#2 iX still has the opportunity to beat OMV hands down by providing working compose out of the box rather than relying on a two-stage installation process by the user. ↩︎
1 Like
These types of situations typically cause more harm than good for the end user and I wish the Linux community would understand or step back and try to understand the bigger picture sometimes instead of trying to create a market where one isn’t necessarily needed (spend time improving the infrastructure instead reinventing it).
This guy does a pretty good job outlining some of the aspects.
1 Like
OpenZFS is under active development and adds new features all the time. Some of the new features break backward compatibility so that an older version of OpenZFS can’t import a pool with those newer features enabled. Some people consider a specific new feature very important, thus enable it as soon as it is released. Regardless if doing so breaks backward compatibility.
One key difference between Sun Solaris ZFS and OpenZFS, is that OpenZFS lets you pick and choose which features to enable. (TrueNAS GUIs will enable all new features if requested… though their is a warning now that doing so can break backward compatibility.)
For example, the Linux desktop I am using right now, has OpenZFS version 2.2.3 with these pool features below. I’ve not bothered to enable newer features I don’t use. For details of the features, the manual page zpool-features has the information.
rpool feature@async_destroy enabled local
rpool feature@empty_bpobj active local
rpool feature@lz4_compress active local
rpool feature@multi_vdev_crash_dump disabled local
rpool feature@spacemap_histogram active local
rpool feature@enabled_txg active local
rpool feature@hole_birth active local
rpool feature@extensible_dataset active local
rpool feature@embedded_data active local
rpool feature@bookmarks enabled local
rpool feature@filesystem_limits enabled local
rpool feature@large_blocks enabled local
rpool feature@large_dnode disabled local
rpool feature@sha512 disabled local
rpool feature@skein disabled local
rpool feature@edonr disabled local
rpool feature@userobj_accounting disabled local
rpool feature@encryption disabled local
rpool feature@project_quota disabled local
rpool feature@device_removal disabled local
rpool feature@obsolete_counts disabled local
rpool feature@zpool_checkpoint disabled local
rpool feature@spacemap_v2 disabled local
rpool feature@allocation_classes disabled local
rpool feature@resilver_defer disabled local
rpool feature@bookmark_v2 disabled local
rpool feature@redaction_bookmarks disabled local
rpool feature@redacted_datasets disabled local
rpool feature@bookmark_written disabled local
rpool feature@log_spacemap disabled local
rpool feature@livelist disabled local
rpool feature@device_rebuild disabled local
rpool feature@zstd_compress disabled local
rpool feature@draid disabled local
rpool feature@zilsaxattr disabled local
rpool feature@head_errlog disabled local
rpool feature@blake3 disabled local
rpool feature@block_cloning disabled local
rpool feature@vdev_zaps_v2 disabled local
3 Likes
I suspect even more “some people” enable new features because it’s there, without needing it, and not realizing what it really does. Just like those “some people” also update the day the new Scale versions come out.
3 Likes
To be fair, ZSTD compression is something that is useful, even if it breaks backward compatibility.
But, your point is well taken. Some / many people just push the button the GUI to enable all new features, just because they can.
I was working at Sun Microsystems, (before Oracle bought them), and I heard customer complaints about destroying larger ZFS datasets or snapshots. Some would reboot and not realize that restarted the ZFS destroy all over again. This has since been "fixed" in Solaris.
One of the first new features OpenZFS added was asynchronous destroy, which eliminates most performance problems with destroying larger ZFS dataset or snapshots.
2 Likes
Oh I was not disagreeing with some needing new features, absolutely! I use zstd. I was just adding to that thought.
2 Likes
iX decides they need a “TrueNAS for Dummies” product and either create it themselves or hire it out, calling it, I don’t know, maybe half-truthNAS.
It’d be called LieNAS - a synonym for Linus! /s
I’d be willing to spin up a VM (not with any of my real data) to test out HexOS when it’s released. Although the name kind of makes me giggle because in Indonesia, ‘hexos’ is a lolly.
Regarding OMV and ZFS, it works reasonably well assuming you switch to using the pve kernel which natively supports ZFS, which the omv-extras plugin has a simple toggle for enabling. Otherwise you end up using dkms and run into potential problems with kernel upgrades if one doesn’t lock that down.
I used to run OMV, but after going ‘all in’ on ZFS, I wanted to run it on something that runs it natively without relying on a plugin.
2 Likes
You mean…
That you agree that you can still import the pool?
“Data loss” was the issue, I thought?
"
I agree that in practice importing a pool should work across many a system. However, I also don’t put it beyond Linus and & co to make ZFS feature changes that are only native to their implementation. Maybe I’m too paranoid.
"
You are not paranoid, you may just trust in the wrong people:
Again, I am talking about STANDARD ZFS implementations.
Anything else that a regular Ubuntu, or TN Scale cannot import, I do not care, or will ever use or help recover.
Thanks for the report!
This, however, is a prime example of the kind of technicality which would make me very, very wary to use ZFS in OMV or recommend it to someone.
1 Like