121–130 of 352 posts
More importantly Red Hat has deprecated FCoE in RHEL, which is big news, because at a previous $JOB they went all in on FCoE because it was supposed to be the future.
Unless you have lots of bandwidth in said adaptor (ie 56gig inifiband) you are going to get contention between network and disk IO.
Earlier quoted context omitted.
> Will you really need and use subtrees/snapshots/XYZ on your system? It's a valid question, but not the best one. Almost nobody needs snapshots. But they make things easier. You most likely don't need a journaled fs in your laptop either (battery level notification should take care of the issues). But it does make life better. "Need" is not the threshold I'm interested in. Most features, I'd like. One feature I thin…
"Need" as in "will you use it?". I played around with snapshots once and never really used them. So i clearly don't have a need for them on my laptop. Journaling on the other hand helps data safety a lot and i think it's not overly complex. I've had data loss happing in the past before journaling, but never again since then. So, wouldn't i need CoW for even better "data safety"? Maybe, but since i've never experience…
Well, many of us have experienced a botched system package upgrade or two. If the file system supports snapshots, then the package manager could automatically ensure fully atomic package upgrades.
That should be reason enough, I should think.
Re: The data loss issue: Yes, I've actually have XFS completely throw away a file system upon a hard power-off + boot-up cycle. (This was ages ago, I'm sure it's improved heaps since then.)
More importantly Red Hat has deprecated FCoE in RHEL, which is big news, because at a previous $JOB they went all in on FCoE because it was supposed to be the future.
What's the replacement then? ISCSI, or going back to FC? Or is everything cloud something these days? :)
I have used Btrfs in production and I would say it's great. It's super easy to just add an extra EBS volume and attach to a Btrfs volume and now you have more disk space. Performance is good enough for me as well, I used it as storage for InfluxDB and Docker. Luckily this is only Redhat, not Btrfs itself.
Unfortunately, RedHat tends to be the trendsetter in the Linux world. Once it's gone from RHEL, it'll be gone from most other RPM based distros soon enough. It's kind of a shame that one company has grown to dominate the Linux software ecosystem, often to the detriment of all involved.
Btrfs is definitely not gone from Fedora, for example.
(Disclaimer: I'm on the virtualization team at Red Hat).
Well I used btrfs as a root filesystem for quite a while, until I realized it was pig slow for sync() -- I mean, it would take AGES to do and apt-get upgrade for example. I ended up having to do some tasks using 'eatmydata' [0] to make it all better, risking filesystem corruption in trade for speed. Also, at the time, there was no functioning fsck. So I moved back safely to ext4 and never looked back! [0]: https://ww…
Over the recent years on every new laptop install i switched between filesystems, so i had ext3/4, btrfs and (currently) xfs on my system. I have to say, btrfs had the most glitches (a few years back), although it worked ok'ish (no data loss). Nowadays, i must say that i very much prefer a stable filesystem with as little complicated logic as possible. I actually never use snapshots or subtrees! I never put another d…
I also really like that I don't need to partition my disk, if it turns out that /tmp needs > 10% of the disk for whatever reason: no problem!
And as I like my data, I appreciate checksumming and copy-on-write.
I haven't noticed any bad slowdowns compared to ext4 on my Debian laptop I used before.
Earlier quoted context omitted.
EPEL gets security updates just like fedora does. Packages are usually maintained in the same gut repositories. However there is no guarantee that you will receive security updates as there is no support contract. But you have a similar problem in Debian if the maintainer isn't keeping up
Debian doesn't have this problem: the security team is collectively responsible for making security updates and frequently creates updated packages without maintainer involvement. I'm not familiar with the Fedora process, but they seem to have a security team and a system of security advisories, which EPEL does not appear to have. Doesn't sound like the same at all. Sure, most of the time packages in EPEL (and in Ubu…
How can they do this if a packaging (and especially backporting) a fix requires deeper knowledge of the package which probably only the maintainer has?
Earlier quoted context omitted.
Facebook, Fujitsu and SUSE are all actively contributing to btrfs. The idea it isn't getting "the man hours from any commercial sponsor" is ludicrous.
And this is what makes me worried about the design of btrfs. If after all these man hours Redhat thinks it still is not stable enough I worry if it ever will be.
Earlier quoted context omitted.
Redhat is worth billions of dollars. Someone must be using Redhat.
Tulips were sold for ridiculous prices, yet nobody used them.
Revenues in FY2017 were almost $3 billion per year.
Earlier quoted context omitted.
Well, for those of us that have been waiting on btrfs for a frigging decade I get the feeling that it is never going to be ready. If I wait another decade, will btrfs have matured? Will there be ANY half-modern filesystem for linux? I'm not convinced. Currently bcachefs seems more appealing but well, long way to go there as well.
What problems have you had with Btrfs recently?
Sorry, but I don't believe enough in btrfs to try it out for real (and don't have time to play with it just for fun). Especially when playing with more advanced features, the status page does not inspire confidence.
The paragraph on btrfs in https://www.patreon.com/bcachefs seems spot on and exactly the feeling you get after spending a decade of hope on btrfs. And that kind of review is exactly what you don't want on the brand new finally-we-can-store-data-properly-on-linux solution.