Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

phoronix.com

Post reply on HN
Print view View original

201–210 of 231 posts

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#201

Post by chasil »

cosmojg wrote: post #149
chasil wrote: post #55

Earlier quoted context omitted.

Btrfs is able to do one important thing that ZFS cannot: defragment. I see XFS as the performance leader (appears on TPC.org the most often that I can see), btrfs as the fullest featured, and ZFS with the strongest reliability.

XFS is the best filesystem for people who don't want to deal with filesystems. Btrfs is there for the rest of us.

As far as that goes, Oracle prohibits the installation of their database on btrfs (note 2290489.1: "Oracle DB has specifically said that they do not support using BTRFS filesystems... BTRFS is optimized for non-database workloads.").

XFS for databases is what is used on tpc.org, but perhaps these new improvements may help.

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#202

Post by chasil »

cmurf wrote: post #154
chasil wrote: post #49

Earlier quoted context omitted.

Regarding resilvering, I am amazed by ZFS' capability of quickly bringing a stale mirror back into synchronization. I have used the FUSE port of ZFS to write only one member of a mirroset, then upon mounting both members elsewhere, the stale mirror was very quickly resilvered, so ZFS was able to determine only the blocks needing to be refreshed. In btrfs, I understand that this requires a rebalance, which will read/w…

Scrub, not balance. It's primarily a read operation. The on-disk format has all the information needed to do an automatic abbreviated scrub, but the feature isn't implemented yet.

No, I've heard that a scrub will not reallocate missing blocks on mirrors. A rebalance was required in the article below, and this situation really requires attention.

ZFS is far friendlier in a crisis.

"We'll even manually trigger a scrub—a procedure that storage admins generally understand to look for and automatically repair any data issues... even though we manually initiated a scrub and let it finish, our array is still inconsistent and even outright non-mountable, because it ran for a little while without a disk and then that disk was re-added. The command that we were supposed to run was btrfs balance—with both drives connected and a btrfs balance run, it does correct the missing blocks, and we can now mount degraded on only the other disk, /dev/vdc. But this was a very tortuous path, with a lot of potential for missteps and zero discoverability."

https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu...

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#203

Post by krageon »

StreamBright wrote: post #167
encabulator wrote: post #144

Earlier quoted context omitted.

I just finished another late night "thanks" to unknown person who decided to use this approach several years ago while setting up 17 servers that I inherited. The /boot partition of these RHEL machines was put on SD cards, which have been gradually dying. So I got to boot the machine (which is 6000 km away) to recovery mode from ISO and re-create the /boot filesystem on HDD (RAID). Of the 17 servers, only three are n…

So you discovered the well known problem in "IoT" that SD cards should never be used for filesystems that are online 100% of the time? I think the parent views on storage is still valid. Do not boot from the RAID volume where you store many terabytes. I usually have a small mirror SSD for the OS (like 128G or max 256G). Those drives are super cheap, easy to replace. For the /data I usually use ZFS or mdadm + xfs. Dep…

flash dying after a few years is not exactly weird or unexpected, regardless of the form factor

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#204

Post by timbit42 »

mekster wrote: post #95
eikenberry wrote: post #89

Earlier quoted context omitted.

Ideally on a ZFS replacement that has a compatible license.

Using Ubuntu is hell of a lot faster than waiting for such a file system.

Ubuntu is embracing an extending Linux through it's Snap repo. Dump it now.

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#206

Post by chasil »

mananaysiempre wrote: post #198
cosmojg wrote: post #149

Earlier quoted context omitted.

XFS is the best filesystem for people who don't want to deal with filesystems. Btrfs is there for the rest of us.

Unfortunately, as best as I can tell you can’t shrink an XFS volume other than by completely rewriting it. (Also mkfs.xfs formats with Y2038-susceptible 32-bit timestamps by default, but that can be overriden.)

RedHat 8 and clones began creating safe XFS timestamps in their installers.

I think they are safe with this version:

  XFS (sda1): Mounting V5 Filesystem

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#207

Post by skyyler »

WastingMyTime89 wrote: post #139
skyyler wrote: post #97

Earlier quoted context omitted.

You're pretending that FreeBSD isn't relevant... You're probably behind a pfsense firewall right now. You have probably seen someone playing games on a PlayStation 3 or 4. You've definitely benefitted from the FreeBSD project without even realising. Have you taken a casual glance at the list of FreeBSD contributors?

I know FreeBSD is used by Sony on its console, by Netflix and by WhatsApp. Everyone knows because they are pretty much the sole serious contributors to it. I don’t think it’s particularly relevant nor do I think it’s particularly good to be honest but we are getting far from the initial discussion about ZFS.

>Everyone knows because they are pretty much the sole serious contributors to it

You haven't even looked at the list have you?

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#208

Post by michaelmrose »

happymellon wrote: post #166
jiggawatts wrote: post #75

Earlier quoted context omitted.

The list of bugs and counter-intuitive design decisions in BTRFS RAID should make anyone pause before ever considering it as a viable filesystem for anything . It's like people justifying MySQL saying that it's okay for it to lose or corrupt data, and that transactional integrity doesn't matter as much as people say it does. Yeah, maybe if you're website is a blog. But anyone storing real data should run away screami…

I've had more issues with my ZFS arrays than the BTRFS ones. The Linux implementation is pretty awful, with it demanding that it uses the absolute `/dev/sdx` reference even if you try to build it using serials or other unchaging reference. Replace a disk and then after the next restart it fails to bring up the RAID because `sdf` points to a different disk. At least BTRFS uses internal UUIDs so can bring up the arrays…

I think the advice was to simply use /dev/disk/by-id/foo when originally creating a pool and one would never have a problem with /dev/sda being a different disk and this was true at least back to 2015ish.

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#209

Post by _kdave »

ilyt wrote: post #127
viraptor wrote: post #14

Earlier quoted context omitted.

Ideally we'd be working based on actual information rather than global mindshare. There will be guinea pigs to test it. There are already quite a few people running it despite the warnings. As much as I want to see a wide use of bcachefs, it's still years away. As someone who actually wants to store data - why would you direct resources to bcachefs which is known experimental, rather than btrfs which plainly document…

Right but "actual information" here is "developers over and over fail to nail what ZFS and MDRAID did well decades ago". There is no reason to trust their next try will be "the one"

MDRAID had write hole until 4.4 (2015, https://lwn.net/Articles/665299/) and it had been long awaited back then. ZFS to my knowledge deals with that by variable stripe length that has its own problems but yeah it works. Btrfs changes implementation of the stripe update while preserving the on-disk format (i.e. can't do the same as ZFS without introducing incompatible change), intent log/bitmap have been proposed (which would be the MDRAID approach) but that's another incompatible change. So the 'next one' is at the cost of performance but with same compatibility.

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#210

Post by _kdave »

linuxandrew wrote: post #160
alerighi wrote: post #91

Earlier quoted context omitted.

I don't get why you need to do so. RAID is not a substitute of backups, and shouldn't used that way. Meaning that of course you have a backup of the data that you can recover from. RAID is used for two things: 1. improving the performance of slow disks (at least the read performance) 2. having 1/2 disk fail with your system remaining completely usable, till you replace the faulty disk as soon as possible. The second…

3. Prevent bit-rot w/ software RAID. Running ZFS, btrfs et al. on a single disk can detect bit-rot but not repair it.

By default the metadata profile is 'DUP' (i.e. 2 copies on one device), the same can be done for data but this reduces the usable capacity. On normal HDD or SSD this should not be needed but having both data and metadata DUP/DUP has been useful on raspberry pi with the micro SD card storage. It's not perfect but increases the chances to get the data back if the card is partially damaged due to power spikes.
Post reply on HN