Hint: :q!
Community rules (click to expand)
sudo in Windows.Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
The CoW nature of Btrfs means it's often slower than ext4 for common tasks, right? It also means more writes to your SSDs.
I've stuck to ext4 so far, as someone who doesn't really have a need for snapshotting.
Edit: I'm not an expert on file systems in the least, so do chime in if these assumptions are incorrect.
Meh, ssds are basically cow by nature anyway, you have to erase large blocks, you can't just rewrite into them.
But if the file system needs extra writes anyway for CoW, and the SSD needs its own CoW, then wouldn't that end up being exponential writes? Or is there some mechanism which mitigates that?
The fs does cow then releases the old block if appropriate.
The ssd has a tracking map for all blocks, it's cow relies on a block being overwritten to free the old block.
Basically it works out the same either way.
Thanks
It's interesting, however, if you mkfs.ext4 without -E ssd, or through some weirdness in your driver chain the filsystem doesn't know it can discard, then everything everywhere sucks for everyone, a cow fs is worse because no blocks are ever overwritten till the end, and the block map becomes a disaster while performance goes down the drain.
Nowadays this rarely happens outside of very broken USB mass storage chips.
This is why we used to have the fstrim command.
Wtf lol
what's the advantage of raid 5&6 over something like raid 4&5 - it reads essentially the same to me - a parity redundancy.
6 is preferable over 5 because with today's disk sizes, swapping in a new drive and resilvering it (full disk write basically in terms of amount of data) takes so long that statistically you might just encounter a second failure during that, which for raid 5 would mean complete failure of the array.
Of course, that's just an uptime issue, since raid is not backup.
4 is bad because parity is on one drive so no matter what happens that drive is the write bottleneck. Raid5 is basically raid4 + raid0.
5 is just fine but low safety, I run 6 always and it has basically never let me down.
As someone who uses openSUSE, this is great I love it.
ZFS: π
I wish the licensing would be Linux compatible
Overall solid but BTRFS has the advantage of being Linux native in the way it works. Right now I wouldn't use btrfs for a critical raid system but it is great for single disks.
I zoomed in to read what they're saying on the bottom right and was disappointed.
That surgeon general's warning sent me into a giggle fit.
Hot format. Invest invest INVEST
IDK what they mean by better ssd I/O performance, btrfs was the worst FS I tested for some heavy SSD workloads (like writing thousands of little pngs in short time, file searches, merging huge weights with some paging)β¦
The features are fantastic, especially for HDDs, but itβs an inherently high overhead FS.
ext4 was also bad. F2FS and XFS are great, and I've stuck with F2FS for now.
idk man I just wanted to make a funny meme I've never run benchmarks myself and I just use btrfs for the features
Oh cool! Share the funny meme when it's done.
(just pulling your leg. ^^)
What's the problem with btrfs really?
It is nice but it also feels like it is perpetually unfinished. Is there some major flaw in the design?
The main one is how it handles corruption. It has actively been designed to do the exact opposite of what a sane filesystem should do and maximises downtime.
It shouldn't be that hard to patch it so that it works around failures. I'm not sure why that doesn't seem to be a config setting.
Mostly just the RAID5 and 6 instability, it's fantastic otherwise. But I'm kinda excited to try out bcachefs pretty soon, as well.