So how long until systemd-somethingmajor requires btrfs?
Btrfs Coming to Fedora 33
101–110 of 140 posts
Re: Btrfs Coming to Fedora 33
#102For 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…
Checksums so I don't backup corrupted data and never notice.
Instant, unlimited, zero-weight snapshots. You'd be surprised how often you use snapshots when you have them. A couple weeks ago I screwed up a save point in a game. Instead of just living with my mistake, I rolled my Steam directory back an hour.
Transparent compression.
Re: Btrfs Coming to Fedora 33
#103Earlier quoted context omitted.
Is that stable?
Alright, so, disclaimer, I have lost data doing this but it was purely operator error! Closed my SSH session at the worst possible time. One of the podcast hosts at Linux Unplugged made the same mistake. The btrfs-convert tool hypothetically leaves the ext filesystem all but untouched, and COW's the needed filesystem metadata onto the end of it, with data modifications coming thereafter (or intelligently stored withi…
I suppose I wouldn't need to worry about an SSH disconnect while working on localhost, but I'd still be a little concerned about trying it. I recently had a Pop!_OS/Ubuntu system irreparably damaged during an upgrade because the lock screen come on during the five minutes I had stepped away from monitoring to use the bathroom.
The wiki also doesn't mention how well this process plays with LUKS, so, given how sensitive headers and such can be, I'll probably wait to hear from some F33 early-adopters on the conversion tool to see how it turns out. I'm reasonably happy with my ext4 system as it is, and most of my core data is on backup disks anyway, so I'm not sure how much the integrity checking of BTRFS would help. Seems like it would be more critical to have on the backup disks to make sure I'm not propagating the bit-rot.
Re: Btrfs Coming to Fedora 33
#104Re: Btrfs Coming to Fedora 33
#105Is 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.
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.
Re: Btrfs Coming to Fedora 33
#106Earlier quoted context omitted.
That is like asking to move to a different house because you don't like the color of the walls.
To use that analogy, no, its more like moving to a different house because lead paint remediation is too costly and error prone.
That seems like an entirely different analogy and basically just says this apartment is bad, you should move.
Then why did you move in in the first place?
The point is, you chose your distro for a reason and one little piece of software is far from enough to override that.
Re: Btrfs Coming to Fedora 33
#107Earlier quoted context omitted.
>databases, VMs, etc You should disable CoW and Caching on the filesystem/-set where VM and Databases-files reside, but that counts for ZFS as well...well for all CoW-FS's in fact.
I don't think CoW can be disabled on ZFS... which is fine because VMs and databases pretty well with ZFS, even with CoW (a block size adjustment might be needed, though).
How does ZFS avoid the performance pitfalls of btrfs's CoW implementation for VMs and databases?
Re: Btrfs Coming to Fedora 33
#108It's painful to see how much disinformation (even in subtle ways or to go off the rails) some topics are getting in here.
If you want to get a better picture, also about Zfs and Fedora, read the previous Btrfs threads where the developers took the time to discuss it. And to kill some FUD.
I have no association with Btrfs or Fedora but I'd like to have a modern FS in-tree as battle tested as it can be.
Re: Btrfs Coming to Fedora 33
#109btrfs 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…
> For data, it should be safe as long as a scrub is run immediately after any unclean shutdown Note that btrfs-scrub (according to the docs) is looking for on-disk block errors, comparing the data to the CRC (or whatever algo) to see if that matches. If it can recover the original data, the bad block is re-written with the correct CRC. So btrfs-scrub does not find or fix any errors with the filesystem structure. For…
This is true, although since kernel 5.2, and continuing to be enhanced, is the tree checker. There's read time and write time tree checking that can catch specific errors in the file system and prevent further confusion. This usually means it goes read-only.
In the most typical case where you have a crash or power failure, you just reboot normally. No file system check happens nor is it needed. It just continues from the most recent successfully committed transaction. Since it's copy-on-write, there's no inconsistency in the file system, even if the most recent changes might be lost.
Re: Btrfs Coming to Fedora 33
#110Earlier 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…
> Btrfs requires a regularly run administrative task via "btrfs balance"
This hasnt been my experience within the past few years, though I do remember it being somewhat necessary in the past. Both systems I'm running btrfs on have their free space within a few percent of the unallocated space (indicating most used blocks are fairly full and little space is wasted).