I did this was going to be about the Vista and how some of the FS stuff that got cut was prescient. "This old thing that didn't work was ahead of its' time" is a whole genre of post (ex. Itanium)
I agree. You have to be a certain age to remember that a big part of Microsoft "Longhorn" was WinFS (Windows File System), which was intended to completely rework storage into a relational file system (or object-oriented depending on your view). "Longhorn" was supposed to do away with NTFS and failed miserably at that objective. I believe that WinFS delayed things considerably and eventually didn't ship with Vista.
Microsoft Longhorn's failure to be the next big thing was largely due to the bad implementation of a storage subsystem. The result was Windows Vista, which was derided as a bad OS (at least until Windows 8). Due to that history, I would not name any file system 'Longhorn'. It may not be the same as naming a cruise ship 'Titanic', but you wouldn't name it 'Iceberg' either.
Anyone knows what's the story with NVMEoF/SPDK support these days? A couple years ago Mayastor/OpenEBS was running laps around Longhorn on every performance metrics big time, not sure if anything changed there...
I tried longhorn on my homelab cluster. I'll admit it's possible that I did something wrong, but I managed to somehow get it into a state where it seemed my volumes got permanently corrupted. At the very least I couldn't figure out how to get my volumes working again.
When restoring from backup I went with Rook (which is a wrapper on ceph) instead and it's been much more stable, even able to recover (albeit with some manual intervention needed) from a total node hardware failure.
Where I work, we primarily use Ceph for the a K8s Native Filesystem. Though we still use OpenEBS for block store and are actively watching OpenEBS mayastor
(Copied from[0] when this was posted to lobste.rs) Longhorn was nothing but trouble for me. Issues with mount paths, uneven allocation of volumes, orphaned undeletable data taking up space. It’s entirely possible that this was a skill issue, but still - never touching it again. Democratic-csi[1] has been a breath of fresh air by comparison.
Kubernetes CSI drivers are surprisingly easy to write. You basically just have to implement a number of gRPC procedures that manipulate your system's storage as the Kubernetes control plane calls them. I wrote one that uses file-level syncing between hosts using Syncthing to "fake" network volumes.
It's simple enough, and I moved from Longhorn to NFS for my homelab as well, but I bristle at needing to have the same unix UIDs everywhere that wants to mount or serve an NFS volume. It seems like a huge layering violation.
I "just" want to expose storage over the network (I don't really care about the protocol, NFS would be fine) with a pre-shared secret or something like that.
edit: NFS really goes poorly when containers want to chown things, now I need to have a 'postgres' UID that's the same everywhere?
not really sure about permission things, but basically it just dump all your data inside the server and many applications are accessing it. i think it's really depends on your application
23 comments
[ 4.5 ms ] story [ 50.3 ms ] threadSincerely, a lover of Gemini (the protocol, and the AI) and Gopher (the protocol, and not the language).
Microsoft Longhorn's failure to be the next big thing was largely due to the bad implementation of a storage subsystem. The result was Windows Vista, which was derided as a bad OS (at least until Windows 8). Due to that history, I would not name any file system 'Longhorn'. It may not be the same as naming a cruise ship 'Titanic', but you wouldn't name it 'Iceberg' either.
When restoring from backup I went with Rook (which is a wrapper on ceph) instead and it's been much more stable, even able to recover (albeit with some manual intervention needed) from a total node hardware failure.
[0] https://lobste.rs/s/vmardk/longhorn_kubernetes_native_filesy... [1] https://github.com/democratic-csi/democratic-csi
https://kubernetes-csi.github.io/docs/developing.html
There are 4 gRPCs listed in the overview, that literally is all you need.
Allowing anyone to delete all your data is not great. When I found this I gave up on Longhorn and installed Ceph.
I "just" want to expose storage over the network (I don't really care about the protocol, NFS would be fine) with a pre-shared secret or something like that.
edit: NFS really goes poorly when containers want to chown things, now I need to have a 'postgres' UID that's the same everywhere?
You need a separate storage lan, a seriously beafy one at to use Longhorn. But even 25Gbit was not enough to keep volumes from being corrupted.
When rebuilds take too long, longhorn fails, crashes, hangs, etc, etc.
We will never make the mistake of using Longhorn again.