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

Btrfs Coming to Fedora 33

fedoramagazine.org

Post reply on HN
Print view View original

111–120 of 140 posts

Re: Btrfs Coming to Fedora 33

#111

Post by cmurf »

eptcyka wrote: post #70
ansible wrote: post #56

Earlier quoted context omitted.

We've recently suffered a catastrophic failure with btrfs RAID-1 on two fileservers recently. They were both RAID-1 with two 4TB drives, stock Ubuntu 16.04. With one of the two, the filesystem was allowed to fill to 99% capacity (no automatic monitoring), so obviously that is operator error, and I'm not aware of any filesystem that can handle such situations gracefully. The system became unresponsive, with btrfs-tran…

I suffered a similar breakdown with no raid. But this was about 5 years ago. The filesystem filled up, had plenty of snapshots, but removing snapshots did not actually clean up any space. Had this happen twice. So I don't think this is related to RAID. Just regular old butter filesystem. On a slightly unrelated note, I once suffered a complete failure of BTRFS where after a shutdown it just wouldn't mount anything ag…

With SSD it's common that they start returning zeros or garbage, sometimes transiently, before they fail. In the case of single device Btrfs, it basically acts as an early warning detection system, and it will be a lot more sensitive to this than other file systems because both metadata (the fs itself) and your data, are checksummed. And the data is a much bigger portion of the payload on your drive. It's way more likely to be hit by hardware related issues, including even memory bit flips.

An inability to mount Btrfs means metadata has been hit by some kind of corruption, and there are more structures in Btrfs that are critical. If they're hit, you see mount failure. And repair can be harder on Btrfs as well.

But it also has a lot more opportunities for recovery that aren't very well understood or discussed. In part because very serious problems like this aren't that common. And also, quite a lot of people give up. Maybe they have backups and just start over with a new file system and restore. Or through no fault of their own they don't persevere with 'btrfs restore' - which is a very capable tool but requires specialized knowledge right now to use it effectively.

One of the things that'll take a mindset shift is the idea of emphasizing recoveries over repairs. One improvement coming soonish (hopefully end of the year) is more tolerant read-only rescue mount option, making it possible for users to recover with normal tools rather than 'btrfs restore'.

Re: Btrfs Coming to Fedora 33

#112

Post by ac29 »

knorker wrote: post #11

Is btrfs still super slow at deleting large files? It can take multiple seconds (like 5-10) on my fileserver to delete just one ~10GB file.

I tested removing a 10GiB file of random data from a btrfs filesystem, it took 254ms.

Re: Btrfs Coming to Fedora 33

#113

Post by codys »

ansible wrote: post #79
codys wrote: post #76

Earlier quoted context omitted.

My experience with btrfs is from a few years ago, so it's possible they've changed the semantics here since then, but this might be applicable: Btrfs requires a regularly run administrative task via "btrfs balance". Balancing consolidates data between partially filled block groups, which will restore consumed space even if a block group is not entirely empty. Typically, one runs balance with a set of gradually increa…

Interesting. I would assume that this is not a factor with RAID-1, where all system, metadata, and data is duplicated. I could see this as being very important for the higher RAID levels. We have since stopped deploying any sort of btrfs RAID (even RAID-1), and have gone back to using Linux MD.

To be clear: I was running a non-raid (single disk) setup where I found `btrfs balance` to be needed.

Re: Btrfs Coming to Fedora 33

#114

Post by chousuke »

nix23 wrote: post #62
pezezin wrote: post #54

Earlier quoted context omitted.

I understand disabling CoW for databases, as the DB itself will manage it, but why disable caching?

In case of Postgres it knows better what to cache, you can let zfs additionally cache but it's a bit of waste, better give that ram to postgres than to Arc.

I think PostgreSQL actually is a bit of an odd one in that it relies on the OS to do proper caching of whatever data is read from disk. It has its own buffers for various things, but I'm pretty sure it doesn't (yet) implement its own disk cache.

Re: Btrfs Coming to Fedora 33

#115

Post by cmurf »

knorker wrote: post #105
cmurf wrote: post #29

Earlier quoted context omitted.

The 'rm' command should complete pretty quickly. Actually freeing up space takes time since a delete is subject to delayed allocation. The default transaction commit time is 30 seconds. And if there are snapshots or reflink copies, a backref walk is needed before extents can be freed.

I'm talking about the time it takes for the `rm` command to finish. I've started the habit of running all `rm` commands in the background on btrfs.

If it's reproducible, my suggestion is to strace the rm command and find out what it's doing that's taking so long; and post it to the mailing list:

https://btrfs.wiki.kernel.org/index.php/Btrfs_mailing_list

Re: Btrfs Coming to Fedora 33

#116

Post by freedomben »

rwmj wrote: post #26
Tsiklon wrote: post #21

Interesting - As RHEL is downstream of Fedora, I thought BTRFS was not being explored further by Red Hat, on account of their deprecation of it downstream in RHEL. If I recall this was because they didn't have the developers able to work on the software, preferring to use XFS + LVM to accomplish some of the goals of BTRFS as their STRATIS project. I wonder what this means for RHEL going forward in RHEL 9?

It means nothing. This is only for the Fedora Desktop spin, and it's lead by the Fedora community not Red Hat.

Disclaimer: I work for Red Hat but I have zero internal insight into this. I'm just a happy Fedora desktop user

I wouldn't say it means nothing because Fedora is looked at as a proving ground for inclusion in RHEL, but I would agree that one shouldn't read much into it.

There are plenty of software packaged/supported on Fedora that isn't and won't be shipped in RHEL. BTRFS may or may not just be yet another one like that. I've heard/seen more excitement about Stratis (which does seem awesome so far) than I have btrfs.

Re: Btrfs Coming to Fedora 33

#117

Post by cmurf »

codys wrote: post #76
ansible wrote: post #56

Earlier quoted context omitted.

We've recently suffered a catastrophic failure with btrfs RAID-1 on two fileservers recently. They were both RAID-1 with two 4TB drives, stock Ubuntu 16.04. With one of the two, the filesystem was allowed to fill to 99% capacity (no automatic monitoring), so obviously that is operator error, and I'm not aware of any filesystem that can handle such situations gracefully. The system became unresponsive, with btrfs-tran…

My experience with btrfs is from a few years ago, so it's possible they've changed the semantics here since then, but this might be applicable: Btrfs requires a regularly run administrative task via "btrfs balance". Balancing consolidates data between partially filled block groups, which will restore consumed space even if a block group is not entirely empty. Typically, one runs balance with a set of gradually increa…

What is the source of "Btrfs requires a regularly run administrative task...".

No file system should require this kind of regular hand holding. If it does, it's a bug, and needs to be reported and fixed, not papered over with user initiated maintenance tasks. It is acceptable to have utilities for optimizing the layout from time to time, but they should be considered optimizations, not requirements. If it becomes required to use them as a work around, that's both suboptimal and neat. But there's still a bug that needs a proper fix.

In the case a workaround is needed, it's recommended to do targeted filtered balances, not a full one. A full balance isn't going to solve a problem that a proper filtered balance can't.

Re: Btrfs Coming to Fedora 33

#118

Post by i-am-curious »

Delk wrote: post #50
bleepblorp wrote: post #22

For desktop use, what problem does btrfs solve better than lvm+ext4? Btrfs is slower than lvm+ext4, doesn't like working with large files, requires more ongoing maintenance (scrub, rebalancing), and is more prone to data corruption. Given that lvm can do snapshots under ext4, the only real benefit of btrfs is btrfs send, but for most use cases that doesn't seem like a large enough benefit to be worth the rest of brtf…

When I replaced the SSD in my laptop with a larger one and needed to resize the partition (and filesystem, etc.) to use the capacity of the larger SSD, I had to do that at least on the filesystem, LVM and partition table levels. Or at least I don't think I found any tools that would have done the entire job for me, because I remember doing the layers step-by-step. If there's no LVM, most point-and-click tools allow f…

Doesn't gparted do this for you? It will automatically figure even the most complex of operations that require filesystem copy.

Re: Btrfs Coming to Fedora 33

#119

Post by cjbconnor »

petre wrote: post #36
ge0rg wrote: post #2

btrfs has made some headlines in the past about its severely broken checksum computation in RAID modes, which rules them out for production use, i.e. https://phoronix.com/scan.php?page=news_item&px=Btrfs-RAID-5... The wrong parity and unrecoverable errors has been confirmed by multiple parties. The Btrfs RAID 5/6 code has been called as much as fatally flawed It would be interesting to know if this has been addressed…

Synology and SuSE are using it in production. I've been avoiding it even though we use openSuSE and it selects btrfs by default.

Synology uses a combination of btrfs and md to avoid btrfs's flaws

Re: Btrfs Coming to Fedora 33

#120

Post by Delk »

i-am-curious wrote: post #118
Delk wrote: post #50

Earlier quoted context omitted.

When I replaced the SSD in my laptop with a larger one and needed to resize the partition (and filesystem, etc.) to use the capacity of the larger SSD, I had to do that at least on the filesystem, LVM and partition table levels. Or at least I don't think I found any tools that would have done the entire job for me, because I remember doing the layers step-by-step. If there's no LVM, most point-and-click tools allow f…

Doesn't gparted do this for you? It will automatically figure even the most complex of operations that require filesystem copy.

I can't remember exactly, as it's been a few years. I'm pretty sure gparted would have been one of the first things I looked into, though.

Looking at my disk in gparted now, while it shows the LVM physical volume (and would presumably allow resizing it if it weren't in use), it doesn't seem to show the logical volumes and their filesystems inside of the physical volume at all. The partition information window for the LVM PV does list the logical volumes, but not the main window where you can plan the changes.

I don't know if that's a general limitation of gparted or if it's a peculiarity with my setup, but that's how it appears to me.

Post reply on HN