Why does RedHat/Fedora devs passionately hate ZFS?
>>106424813Because it's better than their "better"fs (btrfs).
NIH SyndromeSee also:Literally everything else they've made
Legal
>>106424813licensing conflict
>>106424897facebook only owns fedora and can force their fs there. red hat hates btrfs, too.
They just killed bcachefs too. This is why we can't have a nice things.
>>106426019They found out the author is a right winger?
the kernel hates ZFS because of licencing conflicts. ironically, RHEL is the best distro for ZFS right now.
>>106426019>TheyLinus is in no way associated with RedHat/Fedora
zfs is good. ext4 is fine. i've lost data on btrfs. bcachefs is a good idea, but the author's social dysfunction is holding it back.
>>106426736how come you didn't lose data on zfs in 2023 like everyone else?
>>106426773i guess i never hit the bug.
>>106426720https://www.linuxfoundation.org/about/membersIBM, Platinum member, the foundation officially employs Torvalds, I think at $1M a year, last time I checked
>>106426773Probably because he didn't use encryption through zfs?
>>106425675Bizarrely Oracle has btrfs in their own RHEL knockoff but not ZFS.
>>106426773the bugs weren't fixed. last time I checked, they may have only just recently (as in the last month) found the issues that causes native encryption to corrupt their filesystem, and they aren't even sure. They also don't advertise the fact that if you enable encryption, you might lose everything. So clearly ZFS is a fucking clownshow.
>>106424813Not my problem, i'm still on lvm+ext4, i do not care for brapfs nor zozzlefs.
Finally got nixos going in a lab vm after fumbling the configuration for hours. You guys weren't kidding about it being a pain.
>>106429417how's that bizarre? oracle owns proper zfs which only runs on oracle solaris. oracle would never touch this hostile fork of an old zfs version, openzfs, that added a shim for linux.
>>106424813IBM/RH hate superior tech than theirs.
>>106424813Source?
>>106424813RH (not Fedora) also hates btrfs
>>106431802In their defense BTRFS was a piece of shit when it was released, but now it's stable enough.People should just use AlmaLinux now. No logic in supporting Red Hat after IBM's acquisition.
>>106431820alma is no replacement for rhel.alma is a centos stream clone, not rhel. centos stream only has support for 5 years. alma has no idea what to do after that.
>>106424813xfs superiority
>>106431855fedora uses btrfshttps://fedoraproject.org/wiki/Changes/BtrfsByDefault#Red_Hat_doesn't_support_Btrfs?_Can_Fedora_do_this?
>>106431879red hat uses xfs
>>106431846AL 10 has 10 years of support, until 31 May 2035. That is the same as RH Full and Maintenance support.Sure RHEL has 3 extra of extended support but that has a cost and restrictions>"For versions of products in the Extended Life Phase, Red Hat will provide limited ongoing technical support. No bug fixes, security fixes, hardware enablement or root-cause analysis will be available during this phase, and support will be provided on existing installations only."
>>106424941This. People gave shit to Canonical for making their own things like upstart and Unity, while they gave a pass to RH for doing the same fucking thing.
>>106431879>Targeted release: Fedora 33>Last updated: 2021-02-03LOL
>>106431916alma only has a legal source to clone from for 5 years
>>106431927yeah, it's ancient newshttps://docs.fedoraproject.org/en-US/fedora/f33/release-notes/desktop/Desktop_index/#_fedora_workstation_now_uses_btrfs_by_default
>>106431916>>106431952after centos stream eol's in 5 years, alma hopes to clone from other clones. questionable strategy.
>>106431879Btrfs is the default. There's nothing stopping you from picking XFS+LVM in the installer.>>106431700Solaris is on life support. No future releases are planned. If Oracle has any sense, they'll start shipping ZFS kmods for UEK. They'll probably want to keep maintaining their proprietary fork, but if that's not feasible they'll probably try to "adopt" (buy out) OpenZFS. Failing that, just abandon the proprietary branch completely and fork OpenZFS.
>>106431952What source isn't legal?
>>106432009>>106431952That already happened in AL 8 and we still have almost 4 years of support. Building from Centos Streams is easier but not the only alternative. They also said they won't use openELA.>Captcha: 4GAY8
>>106432036RH's as they removed access to the source from non clients.
>>106432036rhel proper would be the illegal sourcehttps://almalinux.org/blog/future-of-almalinux/
https://youtu.be/aMvI5E9-LYI?si=IVl0yHYyxcfyHAkCThe talk on how Alma builds their releases.Even CERN, previous developers from SciLinux, moved to them and they are being financed to support the releases.Out of Oracle, IBM and Rocky, I went with them because they are much less shady.People overestimate what RH actually does with the OS besides the backporting.
>>106432036"Legal" in this case is codespeak for "easy". What they want is SRPMs. Red Hat legally has to provide source code to people it provides GPL binaries to, and said customers can legally share the source code with whomever they please, so they offer the plain text sources through your Red Hat account via some shitty online text viewer to be minimally compliant. You can't just download all the files at once, there's no repo to clone, you don't get to pull all SRPMs at once.
>>106432047>but not the only alternative. They also said they won't use openELA.what new alternatives besides other clones are you alluding to after 5 years? why do you believe in alma to deliver?
>>106426736bcachefs is a terrible name though. Why the hell would you have "cache" in the name when it's meant to be persistent??
>>106429511was only a issue when using send/recv works fine otherwise.
>>106432141Getting from upstream, meaning each package source and forcing ABI compatibility. I would never trust Oracle, they are the reason we have this whole situation as they were aggressive reaching companies to replace RHEL with OL. Rocky founder has drama on him.CERN, who had their own SciLinux which I used in the past, went with AL.I prefer the transparency and the additions they did with 9 and 10, for example, supporting x86_64_v2 in 10.
>>106432154Considering the dram with the main dev, naming is not even his worst decision.
>>106432125why are you leaving out centos stream?centos stream is a magnitude more popular than any other rhel clone since facebook uses it for their giant datacenters.
Just installed Alma Linux with root on ZFS.
>>106432191I don't work in FB and even if I did I have my principles. The change in CentOS left a horrible taste in my mouth, so I rather go with a company that is actually transparent and doesn't tiptoes around GPL licensing to block source access.I understand the problem they have Oracle Linux, but fucking the whole community over it was a tragedy.
>>106432202>using rhel instead of fedora for a desktop
>>106432225and yet you seem to be a prisoner of red hat.others would have left for debian which doesn't have any corporate overlords.
>>106432226That is like comparing Debian with Ubuntu.No need for bleeding edge. A stable system is better than a distro used to prototype the next stable release.I am not him, but I also use AL in all my sandboxes.
>>106432256that's not how kde plasma releases work. you are stuck on a half-broken version of kde plasma forever.
>>106432226I don't want to upgrade release and have my desktop change every 6 months. Also unlike Fedora users, I get prebuilt ZFS and Nvidia kmods.>>106432256>That is like comparing Debian with Ubuntu.Maybe if you're talking about non-LTS Ubuntu releases. Ubuntu LTS and Debian are more similar than different.
>>106432252I only use Debian and Alma.Both are great, love both projects.But in my line I need things that are only supported in RH-likes, so there is no much use on diverging from it.I hate Canonical as much as I hate IBM.
>>106432266Fucking LOL, as if Gnome was anything to write home about.Although KDE LTS is dead, I rather use it then Gnome.
>>106431952Does it really matter for a homeserver. It is basically Centos stream with 5 years where that give extra support if you are to lazy to updoot.
>>106432136Why doesn't RMS sue them? Also seems easy enough to OCR the source code or somehting.
>>106432490Because despite the outrage, they're not doing anything illegal.>OCRNo need, it's literally copypasteable. The problem is that each file is accessed one at a time and there's a lot of files, not to mention additional work is needed to turn pure source code into source packages.
>>106432838Seems easily scriptable.
What about Dragonfly's Hammarfs?
>>106432271>>106432202>Prebuilt Nvidia and ZFS KmodsAnon sama, how?
>>106431855xfs doesn't even compare to the functionality provided by zfs or btrfs. If zfs wasn't licensed until a non gpl compatible license it would have been more embraced. btrfs is starting to almost get feature parity with it at this point and stability so most likely zfs will go away eventually and everyone will use btrfs.
>>106435763>starting to get feature parityoh they fixed raid in btrfs?
>>106435774Look man, I said started. Give them time, they are trying their best and have come a long way desu.
>>106424897um actually, it's btree fs
JFS bros where u at
>>106435763clueless.red hat is building a better zfs on top of xfs: stratis. it's available since rhel 9.3.>In the past ten years, volume-managing filesystems (VMFs) such as ZFS and Btrfs have come into vogue and gained users, after being previously available only on other UNIX-based operating systems. These incorporate what would be handled by multiple tools under traditional Linux into a single tool. Redundancy, thin provisioning, volume management, and filesystems become features within a single comprehensive, consistent configuration system. Where a traditional Linux storage stack exposes the layers of block devices to the user to manage, VMFs hide everything in a pool. The user puts raw storage in the pool, the VMF manages the storage in the pool, providing the features the user wants, and allows the user to create filesystems from the pool without being concerned with the details.>Unfortunately, existing VMFs aren’t easily used on enterprise Linux distributions like RHEL. ZFS isn’t an option RHEL can embrace due to licensing, Ubuntu notwithstanding. Btrfs has no licensing issues, but maintaining up-to-date support for it in enterprise kernels proved difficult.>Rather than writing a new VMF from scratch, Stratis proposes to satisfy VMF-like requirements by managing existing technologies on behalf of the user, so that users can manage their storage using high-level concepts like “pool” and “filesystem”, and remain unconcerned with the more complex details under the covers.https://stratis-storage.github.io/StratisSoftwareDesign.pdf
>>106436935clueless>Stratis is a local storage solution that lets multiple logical filesystems share a pool of storage that is allocated from one or more block devices. Instead of an entirely in-kernel approach like ZFS or Btrfs, Stratis uses a hybrid user/kernel approach that builds upon existing block capabilities like device mapper, existing filesystem capabilities like XFS, and a user space daemon for monitoringand control.This has nothing to do with XFS besides using it as the basis of its filesystem. Stratis builds a layer on top of XFS, not within XFS. Without Stratis you do not get any of these features it mentions while using XFS. Did you even read your own design article?
>>106424813Licensing issue maybeNot a problem on FreeBSD
>>106437199On this >>106432973 FreeBSD?
>>106437271User error. I don't know what the setup is like on FreeBSD but ZFS on Root with Linux is pretty braindead. The only "downside" is it usually means you can't use the nice and friendly GUI installers that most distros provide now a days and have to manually mount and setup things.
>>106437199FreeBSD adopting ZFS on Linux (ZoL) was problematic.ZFS on Linux had to change its name to OpenZFS.FreeBSD project had to fight FUD about ZFS on Linux containing any GPLv3 code.
>>106435203Nvidia provides the prebuilt RHEL kmod in their CUDA repo. OpenZFS provides one in their zfs-kmod repo.
I'm honestly surprised Oracle hasn't found a way to cuck over ever ZFS user and switch the license on them. 2/3 of their company is made up of lawyers, you think they'd figure out a loophole.
>>106437913If Oracle Linux came with native ZFS support I'd use it no matter how much Oracle cucked me
>>106436935I wish they would put that effort into LVM and dm-thin instead of XFS.DM-thin should have per block checksums and diff-on-write modes. At that point even Ext4 can have almost every modern filesystem feature.
Being weary of licensing "issues" on software has got to be the most autistic shit ever.Almost everytime I see someone say ZFS is bad it's always down to muh license, muh out of kernel, etcKind of annoying when you want to know actual code quirks or issues with ZFS compared to other FS
>>106437441What are you even trying to argue?Did you read the comment I was replying to?
>>106437913They're waiting for a fat enough company to start using it wrong and go after them. >but canonicaldoesn't have any money lol
>>106438158It's a RedHat project to fill gaps XFS has. RedHat basically pushed most of their large customers to XFS and now they have to fill their needs. They aren't going to focus on other filesystems. They could have easily focused on btrfs but instead abandoned it and don't even support it on RHEL.
>>106438945DM-thin was a RH project too and LVM thin provisioning is in pretty widespread use, it would make sense to improve it and make it more user friendly.
>ZFShttps://github.com/openzfs/zfs/issues/16993kek, literally made for slowpokes
>>106432838I have seen old rpmsrc, they are very easy to copy and build.
>>106435203Perks of having enterprise distros, companies will provide compatible packages themselves. Lot's of stuff in Arch get those packages and modify them to run on Arch, like Chrome.
>>106435774LOL, never. Just give up on that.
>>106437913>>106438063People would just fork it. It's extremely mature and feature compatible, probably both FreeBSD and Linux devs would join efforts to keep it. It is not a battle worth fighting as Oracle killed SUN's hardware division. Hell, they killed Solaris.
>>106437913>>106438063Oracle's ZFS is close source.OpenZFS came from illumos so they are free from Oracle's license. CCDL is not GPL compatible but it's an open license, there should be no issues as they are self-managed.
>>106439478A database in BTRFS sounds terrifying, not gonna lie. Also BTRFS loses most benchmarks I have seen compared to XFS, so I wonder how they would compare.
>>106439478This was actually an interesting read. In the end you should always finetune memory, cache and FSs for database usage and clearly the person that did it didn't.I would like to see some benchmarks with ZFS and BTRFS is extremely slow compared to other FS.
>>106441219All I'm saying is it'd be nice to see more distros using ZFS out of the box. Not really talking about which implementation or which licence.
>>106441231Just disable CoW for the database directory. Databases are supposed to handle their own integrity anyway. Same with torrents and crypto nodes.
>>106438227It's designed for enterprise storage situations where the company buys sets of HDDs and a server all at once and doesn't change them until the scheduled replacement in 5 years where they copy everything over to a new server / drive set. It didn't support adding disks to existing pools until this year, and if you wanna remove disks or use mixed size you're stuck. btrfs is made to handle cheap ad-hoc storage configs ZFS doesn't want to. Online shrink, mixed size disks, and arbitrary RAID level migrations are mature features.
>>106438227A FS that's not compatible with the Linux kernel license already tells you a lot.Linux has a unified caching system for file operations, block IO (bio) operations, and swap, called the page cache. ZFS is not allowed to use the Linux page cache at all, because such a deep part of Linux’s design can only be accessed via GPL symbols and the CDDL source code can’t rely on them.Therefore ZoL implements its own cache, the Adaptive Replacement Cache (ARC) that constantly fights with the Linux page cache for memory.
>>106437199wrong, ZFS's CCDL license is a viral copyleft license but FreeBSD wants to keep their kernel BSD-licensed. so ZFS is not native on FreeBSD but works thru a Solaris Porting Layer (SPL) shim that keeps the BSD kernel pure.you have the same issue like >>106444069
>>106444069Wut?The ZFS arc has always been a thing before ZoL. As far as the ARC "fighting" for memory, it's always been a thing that the ARC will inflate with free memory and deflate when necessary.Is there an issue with ZoL not deflating the ARC leading to OOM or swap usage?Or is this a Linux brained thing where you expect all FS to conform to the Linux cache system?
>>106444293>Or is this a Linux brained thing where you expect all FS to conform to the Linux cache system?yes, Linux doesn't give you an option to fully opt out of the buffer cache. ZoL hacked around it by invalidating the buffer cache all the time. https://github.com/openzfs/zfs/commit/cecb7487fc8eea3508c3b67810ba5f0e2a265ba1
>>106444470Sounds like a Linux problem for not giving that option.
>>106424813If you actually need those features and are already doing business with redhat, you just use Ceph and a virtualized or containerized solution. ZFS and the like are a relic from when you could get away with one giant server for everything, which makes all of its redundancy and reliability features moot the second something goes wrong with that single server.
>>106444576It does give you the option, just distribute as a patch set. Tons of projects do that, of course to distribute the resulting binaries the license needs to be compatible with GPL.
>>106444592>ZFS and the like are a relic from when you could get away with one giant server for everythingthat's literally the same market rhel aims at.if you want to talk k8s and distributed fs, none of the linux distros of /g/ matter. nor will any of the hyperscalers open-source their distributed fs. ceph remains a poor imitation of google file system.
>>106444592It still has a niche if you care about performance and reliability, but it's a very small one. Neither ZFS nor hardware RAID is actually dead. It just seems like that if you formed your view of the market in the 00s.
>>106445094>that's literally the same market rhel aims at.We must be dealing with different ends of the company then, because every interaction I've had from them is pushing towards their virtualization stuff, openshift, or at least podman.>none of the linux distros of /g/ matterThey do if you have FIPS and other compliance requirements, and while those are pointless box-checking exercises, they still have a material impact.>ceph remains a poor imitation of google file systemAt least in my corner of the industry, the filesystem is the least used part of it. Distributed block devices (the equivalent of a zvol) are mainly what it provides, and every project I've seen is stampeding away from traditional filesystem operations towards object stores for cases where data needs to be accessed concurrently over a network.>>106445357That's kind of my point, its a niche, which is why its not getting any sort of significant enterprise support compared to other approaches.
>>106445501>We must be dealing with different ends of the company then, because every interaction I've had from them is pushing towards their virtualization stuff, openshift, or at least podman.no, red hat is really pushing their k8s distro (openshift) now since even they know that enterprise linux distros are legacy now. none of the hyperscalers build their clouds on rhel.
>>106442659There's two problems here with ZFS adoption:a) Most distributions are hardcore "MUH NO UNFREE CODE IN DISTRO BASE" so they avoid shit like ZFS like the plague. Meanwhile Distros that allow unfree code (NixOS) have it by default as a 1st class citizenb) OpenZFS is slow to support newer kernels. The end result is most distros (out of the box) will only provide support under LTS versions.
How is btrfs still unstable to this day despite being officially pushed by the kernel? Is it intentional sabotage?
>>106445941it's not "unfree", it's just GPL incompatible, meaning it will never be in the kernel, meaning the distros would have to go out of their way to provide kernel modules, which are trivial to install for anyone who wants them. also, people seemingly use ZFS on Arch without problems.
>>106445973Kernel pushes ext4. Fedora pushes btrfs.
>>106446012>people seemingly use ZFS on Arch without problemsNot really. I couldn't find a way to automatically hold back kernel upgrades until ZFS packaged caught up so I had to manually check open-zfs github before each upgrade. The maintained ones were always multiple days and sometimes weeks behind so you had to use zfs-git packages from the AUR and compile them yourself.I can't imagine booting from ZFS. Even with just my game drive on ZFS it was annoying rolling back. Now I'm on artix+btrfs but I hate everything about btrfs, I'm thinking my next distro will be gentoo+zfsbootmenu.
>>106445973It's not. They froze the on-disk format too early so parity RAID is kinda half-ass. It's still usable if you understand how it works, but it's not fit for much besides home server.
>>106446013Kernel doesn't push anything. extfs hasn't been Linus' baby for decades. ext4 and XFS are two competing camps in the high performance space, and XFS is imminently more sensible for traditional desktop because reflink and more efficient / flexible metadata format. The only thing going for ext4 these days is filesystem level encryption, which is more a concern for phones and appliances.
>>106446159I had the same troubles with arch on zfs, even using lts kernel.gentoo seems to work fine since you're compiling it anyway, plus they are quite a bit more conservative with their kernel release schedule, not even lts.
>>106446261have you really had extensive experience with xfs, or are you just old on the advertised features?
>>106446719nta. I've used both and xfs was always faster for me. never understood why ext4 is the default for so many
>>106446320>quite a bit more conservative with their kernel release scheduleI thought gentoo had a bleeding edge kernel in the unstable branch
>>106446731You have to understand some history. xfs was donated and then it didn't have a lot of maintainers. Even filesystem checks for xfs were kinda buggy for a while. Interest in xfs has only really rekindled in the last couple of years. It's also much more complicated than ext was. I think they've ripped out pieces they don't need, but it was dumped into linux as a complex working fs meant for high end computing and everything that entailed.
>muh raidcorpo backers don't really care about single systems much anymore, they want Ceph or similar distributed file systems.
>>106446719I've been using XFS continuously since RHEL 7 and off and on before that since it was added to the kernel. I'm listing features because reflink is an overwhelming advantage if you care about SSD writes. XFS completely obliterates ext4 in practical write overhead. Orders of magnitude difference.>>106446865>Interest in xfs has only really rekindled in the last couple of yearsIt was 12 years ago.>It's also much more complicated than ext wasIn the context of the ZFS thread they're both retard simple. ext4 is Temple OS level retarded where it wastes static disk space for no reason. XFS is merely 90s Unix retarded.
>>106447248So you've been using xfs for around as long as me. 12 years ago is a joke. xfs went through a long phase of neglect. I've had xfs filesystems shit themselves and the repair and check utilities were useless. I moved servers off of xfs during an upgrade cycle because it got that bad, and only THEN did actual work seem to restart on xfs. xfs is not simple. there's still cruft that sgi used lingering in the code--realtime filesystems for example.
I have no idea what you guys are talking aboutI use ext4 and I never notice anything weirdwhat I would want from my filesystem?? Surely its design itself isnt that complicated even though implementation might be?
>>106447335Were you using a smart HBA grandpa? Remember JBOD doesn't turn it stupid.
>>106447372You can't separate design from implementation unless you're writing a basic mtools type program. First rate filesystems are all complicated.>i had problems this one timeIs not an argument because they all have problems.
>>106447372>Generation 0: No system at all. There was just an arbitrary stream of data. Think punchcards, data on audiocassette, Atari 2600 ROM carts.>Generation 1: Early random access. Here, there are multiple named files on one device with no folders or other metadata. Think Apple ][ DOS (but not ProDOS!) as one example.>Generation 2: Early organization (aka folders). When devices became capable of holding hundreds of files, better organization became necessary. We're referring to TRS-DOS, Apple //c ProDOS, MS-DOS FAT/FAT32, etc.>Generation 3: Metadata—ownership, permissions, etc. As the user count on machines grew higher, the ability to restrict and control access became necessary. This includes AT&T UNIX, Netware, early NTFS, etc.>Generation 4: Journaling! This is the killer feature defining all current, modern filesystems—ext4, modern NTFS, UFS2, you name it. Journaling keeps the filesystem from becoming inconsistent in the event of a crash, making it much less likely that you'll lose data, or even an entire disk, when the power goes off or the kernel crashes.
>>106447378I was using EBS mostly.
>>106447572Generation 5: RAID and snapshots?
>>106447774we had RAID before journaling, it's probably Copy on Write.
So do any of the XFS bros in here use Stratis to replicate ZFS features? Is it actually good or a headache?
>>106447811it sounds like a pain in the ass. if I can't use zfs I'll just use lvm.
>>106432154Because it supposedly started off using the same code as bcache, the multidevice cache thing.
>>106447774Copy on Write and data checksums. Having the former makes snapshots trivial, and when you have the latter it makes sense to take over RAID / volume management because you have more context than a strictly block level program.
>>106432009I still kek about this. RH singlehandedly buck broke everyone. Amazon Linux 2 is fucking dogshit unstable Fedora fork, all the fake clones disappeared or basically using CentOS Streams which has shorter life. IBM literally won.
>>106447811It's 'do you actually need zfs' from the people who brought us 'do you actually need docker'. It doesn't actually add anything new.
>>106447491>>106447572I still dont understandI dont notice any difference ever
>>106447893>'do you actually need docker'That's a terrible comparison. Docker/Podman/Kube makes standing up and down stuff so trivial. Not to mention moving between hosts and keeping everything consistent and "just works" with minimal effort. Do people to this day still protest containers?
>>106447811Just use btrfs. No bullshit, it's literally the best FS I ever used. It's literally more flexible than zfs and less autistic in general. It's unreal.
>>106447372>Open file>Write to it>Unexpected shutdown>File now truncated and full of zerosExt4 is literally shit. It's also full of a lot of very weird ass features.
>>106447917There are still people on /g/ who protest systemd and you're asking about containers?
>>106447941that has literally never happened to me and has never happened to me on windows when I used it and it never happened in any filesystem I ever tried
>>106447917>Docker/Podmanpodman is RedHat's 'do you actually need docker'
>>106447941>>Unexpected shutdownNot living in Americas solves this issue.
>>106447976Moving to yurop won't fix my shitty video drivers.
>>106447974Other way around, actually. Docker was "do you really need systemd in a container?" (recall LXC came first) and podman was redhat's "yes".
>>106447976>kernel crashesnow what? You should be using Btrfs or XFS in 2025 and even XFS isn't bulletproof because it isn't CoW.
>>106448018My kernel has never crashed
>>106447962My first real Linux job was basically making sure all file writes were fsync()d because of the very thing I described. Indians would throw a breaker switch to power off all the devices which would cause file corruption if they changed certain things. It most certainly happened 10 years ago and it probably happens today. You can replicate it with sysrq b with enough gumption.
>>106448008That's a different debate. Podman exists because of Docker's root enabled management service. They just glue everything they can together with systemd units and go 'good enough?'
Sun is gone. Why can't the OpenZFS devs just agree to relicense as GPL?
>>106448008wtf? Podman has nothing to do with systemd other than it behaves well with cgroups v2 (when docker didn't) and offers a generator to make unit files.
>>106448062Because openzfs devs don't have all the copyright.
>>106448068There's a long running docker / systemd feud because Docker kept trying to reinvent systemd badly so everything could fit under their support umbrella.
>>106448072Who is holding out on them? Can't we just solve this with some irl "encouragement"?
>>106448079Ya, I vaguely remember. One of the reasons I quickly adopted podman is because it seemed to be well behaved (plus daemonless by default was great). To this day I don't really know what docker actually does that podman doesn't, other than maybe compose, but kubernetes is basically the future anyway.
>>106448095podman-compose exists actually
>>106448082Nah Larry has mad juice. You might as well try to 'encourage' the Rockefellers.
>>106431855it's a perfect filesystem. zfs would've been cool if not for oracle fucking up back in the solaris days
>>106448095The first thing it does well is that its a single binary, while to have podman you need podman, crun, pasta, cataonit, and aardvark-dns (at least, if you are doing rootless, which is the whole point), they all need to be compatible versions, and you need C, Go, and Rust, to compile them all, and you need to make sure you have matching glibc, while docker is pure Go, statically compiled with no glibc if you want.The second thing it did right was come first, which is the primary reason its still around.>>106448102Podman-compose is terrible, a bunch of stuff doesn't work correctly or works differently enough to be a headache.
I just can't see why anyone would opt for RedHat sponsored projects. It's all so opinionated and political charged when they are involved.
I've used OpenZFS on my Debian NAS for about 1.5 years. I'll have to update/reinstall it soon, since I'd like to continue receiving backports. It's been really easy to set up and use. There's no package because of licensing, obviously, but it just recompiles everything when updated. Doesn't take too long either.
>>106424813It's bloated and apperently takes 32+gb ram just to use it
>>106449524zfs existed long before 32gb of ram was even viable. Also your bloated complaint is retarded as it relates to ARC (Cache) which is no different than Linux (or any modern OS) using your unused RAM for cache and giving it back when requested.
>>106449524Imagine going through life just parroting offhand comments you half understand.
>>106448730RedHat is kind of like America. People on the outside cry and shit themselves about the littlest thing they do, and people on the inside barely notice because it's so fucking huge in there.
>>106424897it's butthaFS
>>106432163>only corrupts your data if you use send/recv>undocumentedread my lips, retard: clown show
>tfw Rocky Linux with ZFSbootmenu>updoot from 9.5 to 9.6>no, i don't need to use the handy snapshot feature>boot into new kernel>zfs module not found>boot into old kernel>nvidia is brokenaw sweet, time to set an afternoon aside to unfuck this mess
>>106445501>>106445667Openshift is absolutely RH focus. Just look at their Dev blog. almost everything is AI and/or Openshift.
>>106445973Bcachefs has been a mess and it is(was?) in the Kernel.
>>106446261>The only thing going for ext4 these days is filesystem level encryption, which is more a concern for phones and appliances.Also resizing/
>>106447956There are a plethora of reasons to dislike systemd.ZFS and docker are more a taste than anything.
>>106447974>>106448008Docker is not only inferior but has licensing issues. Podman is probably the best recent RH project.
>>106448018XFS has had CoW for years now, it just got Atomic Writes in 6.16.
>>106447962>that has literally never happened to methat was a famous bug when Ubuntu first introduced ext4 in 9.04. ext4 maintainer was pissed at Ubuntu for shipping a pre-mature version of ext4.https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781
>>106451191XFS doesn't use CoW for everything, just stuff that has been reflinked/snapshotted.
>>106451175red hat gave up on podman. it's not a red hat project anymore.https://www.redhat.com/en/blog/red-hat-contribute-comprehensive-container-tools-collection-cloud-native-computing-foundation
>>106451342CNCF and Linux Foundation are rooted in with IBM and RH, so it's more of a formality. Many of the more mature projects have something related with RH, like Rook.
>>106451375podman is not mature and gave up on reaching feature parity with docker. no one is going to build something like coolify with podman. red hat wants you to use their k8s distro, openshift, instead.
>>106451524Where the money is, K8s, I never saw people using docker, they always go with alternatives.
>>106451524>feature parityIts job is to run containers. It does that just fine.If you want Kubernetes, use Kubernetes.
>>106451600>If you want Kubernetes, use Kubernetes.exactly. don't waste your time with half-effort quadlets, use kubelets.
Why aren't there filesystems which combine data journalling AND CoW.For CoW dirty pages just ignore fsync, also until they get written to disk new data can be directly written to them (only copied on the first write). Only journal gets sloppy fsync to write to disk (doesn't need a strict fsync because of the ordered nature, if there are missing parts in the journal, just rebuild to the last comple fsync).No fsync amplification of CoW, still always able to rebuild the filesystem to a correct state. Perfect for SSDs.
>>106431926they only hated canonical for it because redhat made them angry about it. they needed an exclusive monopoly on cancer>>106432154because it turns your disks into a series of caches. >>106426019btrfs being poorly maintained jeetware is a direct cause of the corporate linux bureaucracy. it's the only fs that gets to survive the linus spergouts. kent made bcachefs thinking the problem with btrfs is the design and not a product of its circumstances, which was a fatal mistake. at least he got kicked out before he burnt out. I am thankful every day for zfs having their toxic license as linus repellant. (btw it's only toxic to gpl2 the same way gpl3 is to gpl2, it's not a bad license)linus is only based for his rants when he is correct. between his thoughts on zfs and lgbt I'm thinking he's often not
>>106451146XFS handles growing better because dynamic metadata size, and I don't think there's a use case for shrinking either of these any more.
>>106424813Because it's the best server fs and they don't control it
>>106453002>best>massive cpu overhead>out of control fragmentation
>>106451600Yeah, its basically the thing that you give developers so they can build and test their containers without needing to push to the cluster/run CI, and without needing to give them root. In that regard, its a success. The rest of the features are timewasters.
>>106451253>9.04.That's 16 years ago, at that time XFS was losing data on EVERY unclean shutdown, full blown filesystem corruption.Hell, even 6 years ago you couldn't count on XFS being recoverable after an unclean shutdown.
>>106452975>don't think there's a use case for shrinkingOf course not, since storage devices have the natural tendency to grow over time. My 512GB SSD has already grown to 600GB, and that's in just two years.If you didn't allocate disk space perfectly when installing your OS, simply wait a few months and then expand whichever XFS filesystem has insufficient space.
>>106453948not true.ubuntu 9.04 had a 2.6.28 kernel. xfs already had those kind of bugs fixed in 2.6.22.
>>106454126XFS had those problems in RHEL 7 which was brand new in 2014 with kernel 3.10.Please don't make me download the ISO and record a short demo, the FreeBSTards still can't recover from a similar adventure.
>>106453986>just keep buying more storage!No wonder the jews (RH) pushes this
>>106425675>red hat hates btrfs, too.Red Hat only hates it because they can't support it.Why do you think they use XFS despite it being an inferior filesystem in every way that doesn't even checksum data (it does metadata checksums only)?Could it perhaps be because they employ most of the XFS filesystem developers and they know absolutely nothing about BTRFS?
I've always used ext4 but I'm wondering if I should experiment with btrfs. On paper it should be better, right? Instant, ZFS like snapshots are probably the best thing about it. But I've heard of nightmare data loss scenarios. I don't know, I feel like experimentation isn't worth it. ext4 just werks.>>106449524You do need a reasonable amount of RAM to use it well, that's true. Not 32 gigs, but at least 8 I think? You'd want more for its caching to be useful. Ideally you just want as much as possible.
>>106455665It's because CoW doesn't scale for big organizations.
>>106447941btrfs rescue zero-log saved me recently
>>106455752Big organisations like Facebook/Meta want these features. You mean it doesn't scale for little/small organisations that don't need data integrity.
https://fedoraproject.org/wiki/Btrfs>Btrfs is the default file system for desktops, starting with Fedora 33.Red Hat doesn't hate btrfs
>>106455786In RHEL they went in the opposite direction and deprecated it:https://access.redhat.com/solutions/197643This is purely because of >>106455665They hire most of the XFS filesystem developers so they're capable of supporting it properly. They don't hire any BTRFS developers.
>>106455803Not sure if im thinking about btrfs or bcachefs? Which ones loses your data if you sneeze and which one got booted from the kernel because the developer was being a giant autist???
>>106455777No, it literally does not scale. XFS + proper backups is a way more preferred solution without completing tanking your FS performance like btrfs and zfs does.
>>106455901>The literal hyperscaler doesn't scaleThey scale faster and better than you and features like BTRFS send/receive will get them there before your backup is even halfway done.
>>106455927If they scale so well then why does RHEL not support them? Checkmate.
>>106455936Because they don't have the developers with the expertise to do so. They have XFS developers not BTRFS developers.
>>106455958If it scales so well they would easily find the expertise to support it. BTRFS isn't some new kid on the block it's been around long enough for there to be plenty of people to hire for it.
>>106455971Filesystem developers don't grow on trees. They tried it and it didn't work out for them. If they hire more developers with BTRFS expertise then it may work for them in the future but not right now. Right now they'll stick with their army of XFS developers that know how to support their filesystem properly.Support here doesn't mean "it boots and works", they had that, but rather "can debug and troubleshoot really hard problems to fulfill our support contract obligations".
>>106455998Ah yes, btrfs is such a great fs that scales so well for mega corps like Meta yet it has a shortage of people who actually know how it works. Makes perfect sense :)
>>106456022There's a shortage because they all work at Meta. If Red Hat wants to poach them they can. One Meta developer recently moved on to work for Anthropic (Claude AI):https://www.phoronix.com/news/Josef-Bacik-Leaves-MetaThese people that have this expertise are few and far between. There's only so many of them in the industry and Red Hat needs people like that to properly support their operating systems filesystem. These people spend loads of time working upstream on the filesystem but also back porting to RHELs custom kernel. You really can't be Red Hat and support BTRFS without a Josef or two. They have these people for XFS, they don't have them for BTRFS.
>>106456050Ah yes, Meta has ownership of all the btrfs devs despite it being one of the best scaling fs. Any other cope you have for why btrfs is so poorly supported?
>>106456055Not all of them. Some of them work for SUSE or other companies. You know where they don't work though? Red Hat.
>>106456061Of course, it's such a great fs that scales the best but only RedHat can't find devs for it.
>>106456070Only Red Hat has unique support contract obligations. Red Hat is a software consultancy company, not just an operating system. They need the developers that work on their filesystem to work for them because of their unique expertise.If they didn't have to support they could just compile the tools and kernel module and call it a day. That's essentially what they did by making it a technology preview. To promote it to a stable and supported feature means they need to hire those people though and they didn't do that.
>>106447880> Amazon Linux 2 is fucking dogshit unstable Fedora forkPeople will blame anything but their own code.
>>106447880>What is Alma Linux?>What is Rocky Linux?
