Twitter Introduces Turn Off Notification From The Strangers. — [SEE HOW...http://mobizone.ng/twitter-introduces-turn-off-notification-...
Btrfs has been deprecated in RHEL
141–150 of 352 posts
Re: Btrfs has been deprecated in RHEL
#142Earlier quoted context omitted.
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…
> 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…
If you're on an SSD/MTD/NVMe, you have TRIM, and scrubbing is a no-op no matter what approach you try. You need a spinning HDD for scrubbing to be useful.
Here is one way to do simple, secure scrubbing on Linux without any intrusive system changes. It is mildly restrictive, but works.
First, you need a small, dedicated partition, but it only needs to be around 16MB or so. Resizing an existing partition down (tune2fs will happily resize a mounted ext4 filesystem, but you'll probably still need to reboot to reload the partition table once you've resized that too) will give you a bit of space.
Now you have a small area of the disk that occupies a known range of sectors, and because you have no TRIM, writes to this area will be properly deterministic. Good.
Create and mount a new filesystem without a journal on the new partition. ext2 could work here (:D), you could `mkfs.ext{3,4} -O ^has_journal`, or you could use filesystem defaults and simply overwrite the entire partition with /dev/urandom later.
Make a sparse file with fallocate (make sure the file system you create the file on can handle sparse files) that is big enough to handle the biggest file.
Create a LUKS volume with a detached header inside the new sparse file, and store the detached header metadata into a file in the new journal-less partition.
Create an ordinary filesystem inside the LUKS volume.
Now you have a Rube Goldberg sparse file. You've moved the deterministic-writing/journal-less stage into a tiny key, which is a lot easier to manage than a whole gigabytes+-large partition.
As an alternative you could drop the key onto a flash drive, and nuke the flash drive when you wanted to kill the data. That's kind of wasteful though (and it carries the same flash-drive-quality risks as copying the only copy of the data itself onto the flash drive).
LUKS was designed such that if you lose the key(s) or the detached header, all that's left is statistically random garbage.
Re: Btrfs has been deprecated in RHEL
#143Re: Btrfs has been deprecated in RHEL
#144Earlier quoted context omitted.
I have one machine running XFS but if that one is representative then I won't be installing XFS anywhere else and would happily discourage others from using it. It is terribly slow when doing some fairly common operations when you have a large number of small files.
You're joking, surely. XFS has outperformed EXT4 in almost all "high" use-cases in my experience and testing: Large files (500GB~) or many small files (128k files * 2,400,000 or so). EXT4 under those loads is comically bad. BTRFS is also terrible at this, only XFS and ZFS are good at handling it.
I wish I was. It's pathetic. Creating a new directory entry on an idle machine with plenty of CPU and memory takes seconds, ditto deletions.
Also: I love how that comment sits at -4, as if downvoting it will somehow discredit the data point.
Re: Btrfs has been deprecated in RHEL
#145Earlier quoted context omitted.
You're joking, surely. XFS has outperformed EXT4 in almost all "high" use-cases in my experience and testing: Large files (500GB~) or many small files (128k files * 2,400,000 or so). EXT4 under those loads is comically bad. BTRFS is also terrible at this, only XFS and ZFS are good at handling it.
I wish I was. It's pathetic. Creating a new directory entry on an idle machine with plenty of CPU and memory takes seconds, ditto deletions. Also: I love how that comment sits at -4, as if downvoting it will somehow discredit the data point.
> I have one machine running XFS but if that one is representative
> Creating a new directory entry on an idle machine with plenty of CPU and memory takes seconds, ditto deletions.
I think your answer lies in your premise then. It's not representative.
Re: Btrfs has been deprecated in RHEL
#146Well 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…
apt-get upgrade syncs so often that 'eatmydata' gives a noticeable speedup pretty much everywhere (I got into the habit of using it for ext3/4)
I don't get why apt syncs so often - isn't the main point of log-structured file systems their ability to recover after a crash or powerloss? If so, why should you need to sync more than one every ten seconds or so?
Re: Btrfs has been deprecated in RHEL
#147Earlier 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…
If you're on an SSD/MTD/NVMe, you have TRIM, and scrubbing is a no-op no matter what approach you try. You need a spinning HDD for scrubbing to be useful. Here is one way to do simple, secure scrubbing on Linux without any intrusive system changes. It is mildly restrictive, but works. First, you need a small, dedicated partition, but it only needs to be around 16MB or so. Resizing an existing partition down (tune2fs…
You seem to be using a different definition of scrubbing than people talking about filesystems usually use.
Scrubbing means to read all the data off a filesystem and compare it against its checksums, so that you are confident nothing has happened to the data (hardware failures, cosmic rays, whatever).
ZFS and btrfs have specific scrub commands that do that.
There's no scrubbing available for a system which does not keep some form of checksum/crc/hash of the data.
I think that you are talking about secure delete procedures.
Re: Btrfs has been deprecated in RHEL
#148Concourse (which is a CI/CD system that orchestrates Docker containers) recently switched from btrfs to overlay to fix performance and stability issues.
For those with morbid curiosity on the many stability issues with btrfs as a container file system, this is chronicled in Github: https://github.com/concourse/concourse/issues/1045
Re: Btrfs has been deprecated in RHEL
#149Earlier quoted context omitted.
I wish I was. It's pathetic. Creating a new directory entry on an idle machine with plenty of CPU and memory takes seconds, ditto deletions. Also: I love how that comment sits at -4, as if downvoting it will somehow discredit the data point.
> I have one machine running XFS but if that one is representative > Creating a new directory entry on an idle machine with plenty of CPU and memory takes seconds, ditto deletions. I think your answer lies in your premise then. It's not representative.
10's millions of files should have been the ideal use case for XFS, that's why I installed it in the first place. This was for the 'reocities.com' project and by the time I realized what the problem was most of the import had already been done so I let it run to completion but it makes updating the project a real PITA.
Re: Btrfs has been deprecated in RHEL
#150Earlier quoted context omitted.
… for which Oracle owns the copyright.
I can't see that the copyright matter here. What matters is the license. Oracle can't unlicence what Sun code is already part of OpenZFS.
But presumably, as copyright holders, Oracle is the entity that could try to enforce CDDL in court, in particular breaking the CDDL by mixing in GPL code in the same (ie: OS) distribution? Oracle goes: we bought Sun, and hold copyright to ZFS (also at the point of the OpenZFS fork) - RedHat could respond: we got a license - the CDDL - and Oracle could respond, sure - but CDDL isn't compatible with GPL - so you're in breach of the CDDL?