What is BTRFS?
Вставка
- Опубліковано 30 лип 2024
- Today I talk about what btrfs is, why it's good, why it's bad, and a few reasons why I think it should be default.
👇 PULL IT DOWN FOR THE GOOD STUFF 👇
Patreon - / thelinuxcast
Paypal - paypal.me/thelinuxcast
UA-cam - / @thelinuxcast
Ko-fi - ko-fi.com/thelinuxcast
===== Follow us 🐧🐧 ======
Discord - / discord
Odysee - odysee.com/$/invite/@thelinux...
TILvids(Peertube) - tilvids.com/c/thelinuxcast_ch...
Mastodon- fosstodon.org/@thelinuxcast
gitlab.com/thelinuxcast
Matrix - matrix.to/#/#the-linux-cast:matrix.org
The Website thelinuxcast.org
Contact us email@thelinuxcast.org
Amazon Wishlist - www.amazon.com/hz/wishlist/ls...
Logo Courtesy of - pedropaulo.net
Intro Courtesy of - www.fragcgi.com/?i=1
Sign up for encrypted email with Tutanota - mail.tutanota.com/signup?ref=...
==== Special Thanks to Our Patrons! ====
thelinuxcast.org/patrons/
==== Referenced ====
Tutorials:
• BTRFS Guide | The Best...
• Modernize your Linux S...
• Arch Linux Install: Ja...
• Btrfs with snapper rol...
• Automatic BTRFS snapsh...
• Debian 12 Bookworm Min...
==== Time Stamps ====
0:00 Intro
1:10 What is BTRFS?
2:33 Copy on Write? WTF is that?
4:25 Why is CoW Good?
4:37 Snapshots!
4:52 What is a BTRFS Snapshot?
7:19 Snapshots Are NOT Backups
8:23 Why Snapshots Work
11:56 The Biggest Reason to Use BTRFS
13:52 Reasons NOT to Use BTRFS
14:19 Very Complicated
17:08 Why This Isn't a Tutorial
20:16 More Negatives
24:11 But You Should Use It
26:14 Snapper and Timeshift
27:45 Upcoming btrfs videos
28:37 Wrapping Up
#btrfs #linux #thelinuxcast - Наука та технологія
This video was released early for my supporters! patreon.com/thelinuxcast and ko-fi.com/thelinuxcast
in Linux Mint btrfs is configured out of the box!
Your explanation is very clear. I can't wait for your tutorial on Arch with BTRFS. Keep the good work!
Thank you for this!
I hope you are able to go through with the mentioned tutorial videos!
It can be quite daunting to understand how to properly set things up so you can take advantage of the snapshot feature.
I’ve only ever used ext3 and ext4 and I’ve been curious about btrfs. This was really informative for me. Appreciate it
Only used ext4 on my Linux systems, so defs has been informative for me too
You did a great job explaining. Thx! 😊 I'm eager to watch any and all videos you make about Btrfs and related topics.
One additional note: Siduction and Garuda also use Snapper/btrfs ootb. Great vid, thanks Matt!
Garuda user here, btrfs really causes more problems than it is worth. I don't think the development team have ever had a handle on it....more of a quirk in their minds.... something to look modern and flash.
i really like the car insurance analogy, because in some ways having car insurance is like having a backup car, but you also know sometimes the insurance company doesn't pay out hahah
Excellent video as an overview and introduction to BTRFS. Thank you.
I've been using BTRFS w/ Snapper on my Garuda Dragonized/Hyprland daily driver for the past 6 weeks or so. Haven't HAD to use it yet but did test it out once & it worked perfectly. Using Vorta/Borg for my traditional backups. Good job on the video Matt, it's not an easy thing to explain in non-techie terms but you did it well. I've also never had any problem with BTRFS. One last thing though is Snapper/Snapper-Tools & Timeshift are in conflict with each other and you can only use one or the other. Garuda installs Snapper/Snapper-tools automatically when BTRFS has been chosen as the file system on initial install.
BTRFS and snapper are part of why my experience with OpenSUSE Tumbleweed has been the greatest Linux experience I've ever had. I had one update bork my system and another time I borked it. Both times rolling back was a breeze, even the first time I ever did it it was easy. Had it been any of my previous distros I would have had to reinstall the OS due to lack of knowledge about how to fix it. I'm thoroughly on the Tumbleweed shill train.
Every modern Linux install should have this capability using BTRFS or not.
I think that will be more common in later distros. I noticed the latest Manjaro had it preinstalled when I tried it out with btrfs filesystem. I actually didn't notice it in the grub menu until I manually edited it for tidyness..lol.
btrfs isn't exclusive to tumbleweed. you can use btrfs on any distro that supports it, most of which these days will. i'm not saying tumbleweed is bad, i'm just saying it's odd that you hold tumbleweed in high regard for what is ultimately a btrfs feature and not a tumbleweed one. openSUSE just defaults to btrfs as the filesystem.
@@gassug2 If you read carefully you'll see that I said "part of" why Tumbleweed is so great. It's far from the one and only reason. Also, currently (or at least when I installed Tumbleweed) BTRFS doesn't come setup with Snapper properly out of the box on every distro that supports it. I've only heard of very few. And it being correctly setup out of the box is part of why it's great. Rollbacks are immediately available.
Thanks -- that was a very clear explanation and run through the issues you need to know about.
This was a crystal clear explanation of BTRFS. Very well done Matt.
great video thank you very much, waiting for your tutorial about BTRFS.
Oh great explanation. Going to have to look further into this.
Nice video, just a suggestion, maybe some visual elements as you were going through different things might be useful for newcomers.
As far as a tutorial for btrfs that would be interesting, don't really care which distro you choose, although as a fellow opensuse fan I would like to see some inputs if opensuse does it differently than Arc. eg. if restoring on Arch is done by xyz , then a "flyby" short for opensuse would be nice. it would act as a comparison as well for people to see how far or close are 2 distros for the same concept.
i got issues with btrfs caused by bad ram years ago, before i pinpoint the ram problem, the more i used the tools to fix corrupt data on btrfs more data got corrupted.
didn't lost all files, just some files at random from the corrupted trees.
i suggest that backups are made in different/maturer file systems.
That's the main reason I don't use BTRFS. I've heard similar stories as yours. I just stick with Ext4. It's never failed me yet. And I just use timeshift.
me too..
Great video , I want that tutorial about arch, and thanks for the video
👍 I wold love to see the Arch video, and I would also love to see what you have done in openSUSE with BTRFS. Thanks for the videos.
Thank you very much for the effort of making this vid! It's very useful.
Great video! Thanks for sharing!
i chose btrfs at my install but i didn't realize i've never set up snapshot or anything. tbh videos like these make me want to do a clean install with the new information i have now just for the health of my machine lol i would love an arch tutorial and thank you for your explanation!
Compression is also a killer feature.
Very nice video. Allow me just one tiny comment... About backups regarding alleged unstability I will add that EVERY system needs backups no matter the file system is stable.
Truth
Your explanations were good. Thank you.
Great explanation Matt ❤
Recently changed /home partition to btrfs with the compress=zstd:1 mount option, mainly to reduce the size of flatpak's .var directory, and it saves ~30% of the total space. And with compression you're mostly limited by compression speed - the speed of decompression is almost the same at all levels, so it might be worth using a higher compression level. Also take a look at how the openSUSE or Arch Linux installers (not based at Calamares) splits the root partition into subvolumes (if you want to use btfrs for this), e.g. it disables compression for /var.
I use zstd:2 where you are using zstd:1. For some directories I went with zstd:9. My reference partitions and my backup disk.
I mount all of my BTRFS partitions with compress-force=zstd:15 and I'll never go back. So fucking worth it. Only wish BTRFS supported even higher compression levels, and that I could defrag everything to forced zstd 15... Currently my root partition as a whole has a 58% compression ratio (108G used, 187G uncompressed, 406G referenced, 100G zstd-compressed down to 21G). My home partition has a 75% total compression ratio with its zstd compressed files compressed down to 39% average. For a particularly well compressed directory, my 50GB /logs directory consisting of 5700 files is zstd-compressed down to 5%, only taking 2.5G of space. My primary external hdd partition as of 2.5 months ago (the last time I ran a full partition compsize on it) has 77% total ratio, 44% average ratio for zlib-compressed files, and a 14% average ratio for zstd compressed files, saving over 1.1 terabytes of space by the zstd compression alone.
@@MH_VOID interesting, but I use compression not so much, because I'm not sure about some things yet:
a) isn’t the log file completely overwritten after appending a couple of lines to it? Theoretically, btrfs may compress the entire file on its modification.
b) how much does the file access time decrease and how much CPU resources does it use? Does this affect the startup time of utilities like `ls` or even `[` or `test`, which all the scripts consist of? This can also drain your laptop battery.
IMHO, there is no point in compressing the root partition and system files at all, since they are read very often and do not use so much space. Also Arch's pacman keeps already compressed downloaded packages in /var/cache.
@@fumanchez > isn’t the log file completely overwritten after appending a couple of lines to it?
The log file for what?? A sane program won't do this.
> Theoretically, btrfs may compress the entire file on its modification.
compression happens per extent (a 4KB (by default) contiguous physical chunk of storage). Each extent is 100% independent from the ones before and after it, I believe. This is how one file can have one part zstd level 9 compressed, another part lzo compressed, a third part not compressed at all, a 4th part zstd-15 compressed, and so on. If the extent is not modified, BTRFS won't change its compression unless you run a defrag on it.
> how much does the file access time decrease and how much CPU resources does it use?
Not enough for me to notice any problems. I just dd'd a 9.3GB log file located on my SSD (for maximum throughput) and compressed all the way down to 3% size (!) and monitored the BTRFS processes' CPU usage and the highest it ever reached was a whopping 0.2%. When you take into account that my CPU has 32 threads, that would mean about 6.4% usage of a single core in a highly demanding decompression task. Pretty damn acceptable in my book for 3300% space savings! And yeah most of the time you won't be getting savings that high, but then again most of the time you won't have a CPU cost that high either. Also keep in mind that if your hard drive read/write speeds are low, this can actually INCREASE the speed at which you read the files, as you can fetch more data at a time from the storage device. If you have a high end SSD and a bad CPU, yeah, you'll be losing out, but otherwise you are quite possibly gaining in total access time, even if time to first data availability will never be faster.
> Does this affect the startup time of utilities like `ls` or even `[` or `test`
I don't see why it would. The file data is compressed if possible, not its metadata. so `cat` would be slower but `ls`, `[`, `stat`, et cetera should be unaffected.
> which all the scripts consist of?
Which scripts?
> This can also drain your laptop battery.
I mean, yeah I guess the compressing and decompressing has an impact on battery life, but probably not one really all that significant, especially one significant enough to not be worth the space savings. Also keep in mind that the kernel will cache the files in memory if they're being frequently accessed, thereby making this less of an issue (For your executable question from before, I think they're often kept in memory so if you e.g. have an ls process running and then run another ls, the second ls won't access the disk at all to fetch its own data. And besides, even if it did, they're pretty small so the overhead would be rather negligible). There's also a counterpoint to be made in that less data is being physically written to storage and so some battery savings (in addition to the obvious throughput and space savings) are being had.
> IMHO, there is no point in compressing the root partition and system files at all, since they are read very often and do not use so much space.
Binaries actually compress extremely well. Right now, my /usr/bin directory is compressed down from 2.0G to 615M. In fact, only 8.9 megabytes across all those executables (and /usr/bin/ is symlinked to /bin and /sbin, so it's really pretty much all of them besides Rust programs I have in a separate directory) were deemed incompressible by compress-force=zstd:15, and so I have 332% space savings there for like no effort. See my previous point about caching too. Also, it's really nice for preventing random log files from filling up your entire hard drive because of some error their program had, causing other programs to fail with ENOSPC - even if you catch it quickly, it's still a pain. You don't really even need to rotate log files anymore, as they're compressed already to a similar extent. And as I said, in my personal case,
> Also Arch's pacman keeps already compressed downloaded packages in /var/cache.
So those files are deemed incompressible and are exactly the same as if you never enabled compression in the first place. There is 0 loss besides the minor one time cost of BTRFS trying to compress it when you first download them.
Oh and as a final point, if you really don't want to deal with any significant additional latency, don't use a high level of zstd and instead use either a low level (1-3 I think) of it or use lzo, where these are made to be realtime. And also then don't mount with compress-force (which will always try to compress every single extent), and mount with just compress (which will try to compress the beginning of the file, then if it can't do so, just write the entire file as-is without compression). I personally would never do that, but you might find it useful, and there's really pretty much absolutely 0 downsides doing that as opposed to having no transparent compression whatsoever.
I hope this helps
Fedora needs some steps during installation to make sure its BTRFS system will work with timeshift, but after setup, it works like a breeze and gave me a great peace of mind. I believe it also needs root access to be enabled for recovering snapshots.
I have had an unrecoverable disaster from BTRFS before. All I can say, is NEVER use the so-called repair utility. Whatever the problem, it will make it worse (though presumably it will be finished and work right someday). Use the scrub tool instead first, which will actually fix most common issues. In my case, it was a checksum mismatch after a crash, which should have been a minor problem, that could have been easily repaired by the scrub tool, had I known before hand. The repair tool just deleted the file and left the bad checksum, so the error could never be resolved, and with a fs error, BTRFS will only boot read-only. But, I live and learn, and despite this experience, I still use BTRFS for my root system.
For backups I use snap-sync to integrate snapshots on other drives with snapper, highly recommend.
Linux mint distro is built for btrfs as it comes with timeshift included. Been using btrfs for 3 years on mint but never once have i touched timeshift tool even though it comes ready to use. But after watching this video, I will start using timeshift. Very informative. Also Linux mint takes care of the subvol for you when selecting btrfs. It set to add subvol by default in linux mint (maybe even ubuntu too). After 3 years not a single issue. It is stable even with kernel 6.2. Btrfs also performs better than ext4. Did some real world benchmark tests. This is why btrfs has been my default since then.
In my experience i never once had a performance issue based on these claims. I have put this filesystem through its paces in a way that NTFS, ext4 got corrupted but btrfs is a champion.
I use btrfs for my main drive and my secondary nvme ssd is using ext4 and is used just for games. I love the ability to rollback to a previous snapshot... currently running vanilla os and the btrfs setup is amazing.
Ihave to arrest you on the BTRFS is unstable bit, the only parts that are marked as such is RAID 5/6. There are a couple of features marked "Mostly OK",which obviously means minor. And most of those are also related to RAID. TLDR: If you run just a single disk there's nothing unstable about it.
Paraphrased from the official status page. :)
Edit: I'm posting link in a reply, so please move it from spam if it ends up there.
It sucks how we can't post useful links any more. Darn bots.
@@mjblcmichael yeah, I see it's gone. @TheLinuxCast if you could dig the post out of spam jail please. :)
Btrfs on Debian Testing (kinda Rolling Release Debian) is a Blessing. It saved my system after a weird Nvidia driver update breakage. (Upgrade from 525.xx to 535.xx)
I think even Debian Stable Users should use Btrfs especially when they thinker with there system.
Thanks for making the "not a tutorial" explanation Video about Btrfs.
Subvolumes are actually a little like folders that contain hardlinks to all its files. You can have a look at them if you mount subvolid=5. 5 is usually the "parent" subvolume of a Btrfs file system.
I could be wrong, but from what I remember it was nicknamed "butter FS" was that it was supposed to be both "better" and faster/smoother, kinda like butter. So I heard a lot of "Better FS" and "Butter FS" when I was playing around with Linux a decade ago.
I should add that I was trying BTRFS out back then in the 2012-2014 area, and always had problems at that time. I was way more inexperienced with Linux back then. In the past 3 years every Linux computer I have set up I have used BTRFS and have had no issues with it. My Manjaro primary system has had it for almost 3 years on a single install (longest Linux install I've ever had) and still runs great!
@@binladen-ci7jm I very clearly said it was a nickname, not the actual name.
@@binladen-ci7jm This is just arguing semantics. They are nicknames, as people, whether through a misnomer or not, call it that. The name they call it is not the official established named, therefor it is a nickname.
@@binladen-ci7jmhave you ever heard of neologism? vernacular dialect? they would be considered misnomers but is not ugly, people just like to use it even being "wrong" and all.
doesn't matter if it is "wrong"... if it sticks, it sticks. And I've to say, butterfs is much cooler.
Best explanation I ever heard of BTRFS. 👍
Arco Calamares still offers Snapper, both are superb. I have found my home in arco i3, first Arch and tiling wm and I am very happy to have chosen the combo.
Fedora does nothing for btrfs snapshots. Just zstd compression, that's all they provide.
True. You have to install and set up snapper manually. Btrfs Assistant is another pretty useful tool.
27:45 Yes! I would LOVE to see you do a tutorial on how to set up BTRFS, at least on Arch and Ubuntu.
I run endevour on btrfs(nvme), and have hdds for data and stuff, so for those hdds is it better to go also btrfs or ext4? What would be the recommendation?
Sounds like a great way to back up my data!! :)
BTRFS is pretty much required with Arch. I used it as a get out of jail card many times. Since switching to NixOS, snapshots are supported out of the box with any file system, so I prefer EXT4 again as I get a quite large bump in performance.
Great video! 🐧
Been using btrfs for about 8 years now on Gentoo and I absolutely cannot go back to a file system that doesn't have snapshots. It's saved my bacon many a time and just makes using your computer way easier. I've even used snapshots to try out a desktop environment and then if i don't like it, i can just go back to my old snapshot like nothing ever happened. And i can't tell you how many times I've accidentally deleted a file i didn't mean to. Well, with btrfs I can just go into my latest snapshot and just cp that one file back over. Or say I just did a bunch of configuration changes and then I'm like aw shit I've made all these changes, but it's not working and i want to see what the defaults were again. Well i can just open up the old version of the file and have it next to my working copy and compare the changes i made. It's just beautiful!
Garuda (Arch) Linux does BTRFS out of the box by default... You don't have to even touch it if you don't want to. It's the best file system in my opinion.
I got a short and cursory introduction to the BTRFS file system when I installed Garuda. Snapper was installed and activated out of the box. (Nice distro, BTW with a ton of features, but a little too much bling for me.) I mainly use Linux Mint and I trust those guys not to bork my machine. I have an ancillary drive with all of my important data, and I did take one snap shot with Time Shift shortly after I installed. If things go completely to poop, I look at it as an opportunity to switch distributions. Haha.
I've been using btrfs on Arch for like a couple of years and never bothered to actually set it up properly so a tutorial would be very nice
Unfortunately if you didn't setup your subvolumes properly then you will probably have to reformat. You took a sizable hit in performance vs EXT4 with no real advantages.
@@bstar777777 yeah probably, haven't noticed anything so far so I prob won't do anything for now lol
As a heavy BTRFS user, my last partition was created via `plz mkfs.btrfs --metadata dup --data dup --checksum blake2 --label 'reddit C&S' --verbose --verbose --verbose '/dev/sdb4' --force`. `alias plz=doas`. I mount it via `plz mount --options compress-force=zstd:15,async,datacow,datasum --label 'reddit C&S' /mnt/rdt`. Tools you should check out are duperemove (for deduping, example usage is `plz duperemove -vrdAh --dedupe-options=same --hashfile="${XDG_STATE_HOME}/duperemove/OLD__duperemove.sqlite3" -- /run/user/1000/no-atime_mb/BKP/ehdd`), and compsize (shows BTRFS file/directory {total,none,lzo,zlib,zstd} {compression ratio,disk usage,uncompressed size,referenced size}). Alias cp to `cp --reflink=auto` (or to `cp --reflink=always` if you want guaranteed reflinking but failure if it'd try reflinking something invalid (e.g. reflinking across filesystems, or on one that doesn't support it (mostly all except BTRFS, BCACHEFS, ZFS, XFS, and I think EXT4)). Personally I have it aliased to ` cp --reflink=auto --archive --verbose`). Periodically run duperemove over your BTRFS partition to free up space without data lossage (though note that it will reflink together files with intentionally-by-you identical but distinct underlying data, as obviously that's the point of it in the first place, so thereon if parts of one of those files is physically corrupted, all the copies will be corrupted as well), and scrub the filesystem every month or so (via e.g. `plz btrfs scrub start /dev/nvme0n1p2`) to detect and hopefully repair in time data corruption. Also (and this is assuming separate root, home, and other partitions) I highly recommend adding to your system update script/alias a command to snapshot your root filesystem (for mine, I appended `doas btrfs subvolume snapshot -r /mnt/defvol/_active/rootvol/ "/mnt/defvol/_snapshots/root-$(date --utc +'%Y-%m-%d--%H-%M-%S.%3N')"`), as that way if something goes wrong you can just `cp -t / /mnt/defvol/_snapshots/root-*(om[1])` or similar (Oh, you should also set it up so those root fs snapshots show up in your GRUB menu or similar so you could just boot directly into it if need be. I don't remember offhand how to do that, and I'd have to look it up with more effort than I care about to expend right now, so I won't elaborate further on this unless prompted by a genuinely interested party). That's basically it. I hope this helps you (or anyone else reading this, for that matter).
liked the background blue light btw
I love the idea of btrfs and snapshots, but since the performance of btrfs is still less than ext4, I'll just stick with rsync/timeshift, for now.
Also.. YES, the setup for btrfs to be useful can be painful. Fedora doesn't set it up, at all, OOB. Apparently OpenSuse(according to you), Ubuntu(from experience) and Garuda(from experience) take care of just about everything for you.
It's kind of annoying how Fedora doesn't just call it @, instead they call the Root subvolume 'root', but it takes a couple of minutes to create a snapshot called '@' and change it in /etc/fstab.
If you had to copy a terrabyte of files to a terrabyte SSD, what do you think the difference between ext4 and BTRFS would be? Assume the latter is setup with zlib:2 compression.
I bet it might be under 20 seconds in favour of ext4. But while the ext4 disk would be full, there would likely be one or two gigabytes available for the BTRFS disk.
@lsatenstein I don't use compression but, I get your point. You're saying the performance difference is negligible. The other kicker is that btrfs shortens the lifespan of your ssd, significantly and to store the backups on an alternate drive(for redundancy) you'd have to transfer the data the old-school way anyways. I think btrfs can be good for a lot of applications... it also is not the right choice for a lot of applications. Ext4 works for everything and doesn't require a ton of thought/setup/tooling.
@@TActually I am on my system 8 hrs per day, 5.5 days per week. At least twice a week I load up two Fedora beta ISOs , together with my other use, amounts to 5 gigs /week, onto a 120 gig SSD. That's been going on for 6 years for that SSD. I do keep about 25gigs reserved for BTRFS pages. Every 2 weeks I run a "fstrim" and a BTRFS compress. The BTRFS runs first to mark its reserved pages free. The fstrim does likewise for the SSD technology. I make use of two crontab entries that I set to run at 8am on alternate Fridays.
@@doesnotcompute6078 you are right about the cost of external storage. My external storage is a hard disk. Here compression on my desktop system is,😍 besides using less space, reducing I/O time.
Btrfs tutorial for Arch would be much appreciated.
Yesss rolling updates. Gentoo user and btrfs has saved my behind
OpenZFS is better, especially if you have a complex set up of a lot of drives.
I also like F2FS too.
I disagree, especially when doing non-RAID setups. I currently use BTRFS as my primary filesystem across 3 drives and like 6 partitions. I think bcachefs will likely be better than BTRFS though. I've never heard of F2FS, but looking it up briefly it looks interesting, though those are some godawful size limits it has (4TB max file size? I've gotten pretty close to that already. Same thing with the maximum of a 16TB large volume). Why do you state OpenZFS is better? AFAIK, it doesn't even have reflinks!
I started using BTRFS because I wanted to use zstd compression, It also has good drivers for windows, so is better than NTFS, to use in both systems (as a secondary drive for win)
So, I watch the benchmarks DJ Ware does all the time and btrfs performs so bad on I/O tests compared to anything else, it's laughable, sometimes as low as half the speed of the competition. He'll often say off handedly when commenting on the benchmarks as they scroll by, "and then of course btrfs is last", as if this is just a given and common knowledge. Like with anything, I suppose that's the price you pay. Redundancy, safety, and security is not cheap.
Btrfs surely is the future for Linux' default filesystem. Apart from snapshots in my opinion compression is a very neat feature, too. Especially if you combine it with snapshots on a small disk to be able to store a lot more snapshots than without compression - I run a Fedora testmachine with only a 60 GB SSD like that. BUT I also think Btrfs needs a little more time and development before I'd want to replace the trusty and super-fast ext4 (fast_commit anyone?) on my main machines and especially on my data drives where I don't want a checksum error or some kind of other hiccup take down the whole drive. Running Debian based distros, I very rarely actually need to roll back a snapshot.
I'm a heavy BTRFS user with 15 terabytes or so of BTRFS partitions. I barely ever use snapshots. Transparent compression is an absolute game-changer (saving me terabytes of space), and so are reflinks, which I heavily use to the point that my partitions usually have like 3 times the referenced data as actual data, and which basically obsolete snapshots for me. The checksumming is also damn nice, and something I'd never go without (even for databases, I'm not going to nocow them since doing so disables the checksumming). I mount all my BTRFS partitions with compress-force=zstd:15, create them with blake2 checksumming (in the past, sha256 and xxhash, but blake2 mostly combines the benefits of both with few comparative downsides), and set dup data and metadata (halving my capacity but still actually coming out ahead when you consider the space savings from compression and reflinking). I will never voluntarily go back to any filesystem that does not have at a minimum reflinking, transparent compression, and extent/block/whatever checksumming (not having data & metadata duplication is fine, since I can always just set up RAID 10 or whatever) (oh and also xattrs and birth times. if it doesn't have that I'm not interested). The most likely thing to get me to move to a different filesystem is supporting even better compression - well, that, or actually doing away with the shitty path & file name limits.
@@MH_VOID Might I ask what kind of data you're storing that you can benefit that heavily from compression? From my experience big disks like that usually are mainly occupied by media files in the private environment. For me, for example, only about 5-10% of my data is reasonably compressable.
*Writes note on forehead* Snapshots are backups. Okay got it.
I've started using Garuda Linux and it also uses BTRFS and Snapshots by default. I like Garuda because it's based on Arch and has been working well for me so far. I have had troubles with OpenSuse and figuring out YAST with Wi-Fi.
I tried installing tumbleweed as 3rd os. I mounted already existing boot efi and swap, formated root as btrfs.
But midway installation there was an error in mounting swap. I proceeded anyway. Now opensusse doesn't have swap
And making a swap is not easy? Takes you 5 minutes including coffee.
In Manjaro I have btrfs and timeshift set up out of the box and I can see snapshots being made before each update. However I've never tried using those snapshots (there was never a need so far).
I would like to thank the Garuda Linux, that made me appreciate the benefits of BtrFS, by forcing me to use it out of the box. It already saved my skin on two separate occasions.
Garuda has snapper, btrfs and grub snapshots out of the box. Although Garuda is great, I deleted in favour of CachyOS but I had to set it up manually with CachyOS. I wouldn't call it unstable either.
Why wouldn't you got opensuse at that point?
@@Destide I did try OpenSUSE. Zypper commands are unfamiliar..so are the package names. That package manager is also quite slow. I like CachyOS better. And I have snapper with btrfs-assistant enabled, so I can always revert back to an older snapshot if a new update breaks it.
My big problem with BTRFS was how darn difficult it is to figure out how much data is stored where. It's not like EXT4, where you just run df -h and get a nice list of how much data is in each folder.
Understanding apfs is also dificult to its Feature Wise its similar to btrfs its just Apples Version of it......
Yeah, that's kinda the biggest downside of it. compsize is damn useful for that purpose though
Is btrfs the reason I can boot into an older kernel version when an update messes stuff up,or is that just a feature of grub/Linux in general?
That's on the distro, from what I understand. OpenSuse, for example, can't do that easily (or at all).
@@DanielCastro-ok8zb OpenSuse can have multiple kernels in Grub, no problem. Type "Opensuse multiple kernel" into your favorite search engine and see. :)
Had major speed/latency issues on writes with many small files 4 years ago in RHEL 8 on lvm in a high volume production system. Had to move back to xfs. For personal use btrfs works well.
Btrfs is much much better at dealing with power loss than ext4. At least in my experience. Ext4 would easily fail at some point in time when doing fsck (after power loss). This reason alone is enough for me to prefer it over ext4. Also btrfs has been incredibly stable, I have been using it for almost 1 year.
Note: You can have snapshots on non-btrfs filesystems by using timeshift with rsync + hardlinks
I decided to try btrfs on Arch because I got sold on its features, but I’ve been having performance issues all the time. The system basically freezes when copying large files. I hope there’s some config tweak that I’m missing or something because if its gonna be like this I’m unlikely to use it ever again
I had freezes in Fedora as well with btrfs. I was able to fix those by using noatime in the disk's mount options. There's a note on that in btrfs's manual.
I generally get away with adding stuff to my system, but there have been some times I more or less regretting doing something. In some cases I just re installed everything which takes usually under a day. I would not personally like to use this sort of thing. One of the biggest problems was when I was looking for a vm that did pci passthrough and I thought boxes is what was available. It turned out after days of trying things that virtual manager just did it already, and very well. When I tried zen it made a complete mess of the system to the level I think it tried to boot linux as hypervised in the first place. Also I generally just turn off updates so I don't get into version problems, but I tried to update certain aspects of the system and then I had to update gcc and also the kernel to make it all work which was a disaster.
I didn't understand the car insurance analogy, what do you mean "If I do go out"? :P
I would appteciate brtfs zfs comparison.
I was surprised to not hear a single mention of ZFS in this video actually AND in the comments
As an arch user I would love a tutorial on using btrfs on top of encrypted volumes with luks
A simple explanation from ChatGPT:
BTRFS (B-tree File System). Imagine your computer's storage as a giant bookshelf. Normally, you'd stack books (files) onto the shelves (file system) without much of a plan. But what if you could make that bookshelf smarter and safer?
Snapshots: Think of snapshots like taking a photo of your entire bookshelf at a particular moment. If you mess up later, spill coffee on a book or something, you can just go back to how things were when you took that snapshot. Handy, huh?
Subvolumes: These are like mini-bookshelves within your main bookshelf. You can manage them separately, take snapshots of them, and even give them special rules. Super useful for organization.
Data Integrity: BTRFS checks your books for you. If it spots a torn page (corrupt data), it tries to fix it if possible.
RAID Support: Imagine having more than one bookshelf and spreading your books across them. If one bookshelf crashes down, you still have your books safe on the other one(s).
Dynamic Sizing: This is like having a bookshelf that expands or shrinks as you need more or less space. No need to buy a new one or throw it away; it adjusts on the fly.
Copy-on-Write (CoW): If you make notes in one book but want to keep the original untouched, BTRFS will create a new book (file) for the notes but won't actually duplicate everything-just the parts that changed. This saves you space.
In a nutshell, BTRFS is like a super-smart, flexible bookshelf for your computer's files, designed to be efficient, protective, and make your life easier.
"Imagine having more than one bookshelf and spreading your books across them. If one bookshelf crashes down, you still have your books safe on the other one(s)."
Yeah that's why I only keep 2-3 books per bookshelf. SO much easier to deal with if one bookshelf crashes down.
Please do a tutorial for btrfs on Arch. That is an excellent idea.
I switched over from Ext4 to BTRFS on SUSE years ago and the only problem I ran into was my disk labeling tool could not deal with them so I had to learn a new way to name my drive "my disorganized crap"
BTRFS is not the best Linux file system, it still had problems with reliability in the more complex configuration and the performance is not very good. BTRFS did steal its ideas from Sun's ZFS. The best Linux File System is OpenZFS and that is, why it is used in the professional Linux products like e.g. Proxmox etc.
I disagree, the only problematic thing now is RAID 5/6. I've ran it for what... 7, 8 years or something now, in both single disk, RAID 0 and RAID 1, no problems at all. For a while we had frequent power brown outs here and I had 0 issues
Sure OpenZFS is great! But, it being outside of kernel is a pain sometimes. Depends on the distro I guess...
But if you're going to go multi disk RAID, ZFS is king right now.
But OpenZFS and BTRFS is similar in performance overall when the disk layout is the same. CoW file systems versus regular ones like XFS and EXT4? Data safety vs speed. Being safe cost performance, just like any other security features. Disable Meltdown et al mitigations, be less secure but faster.
Thanks man, :)
I didn't realize it was B-Tree FS. Binary trees are a lot of fun if you like data structures.
Nice! Now we can play Bash Russian Roulette on our own system.
Not sure if I want to move to btrfs just yet.I also don't know why Oracle decided to create btrfs when they already have the mature zfs. Maybe it's licensing or other issues, i don't care but when it comes to "snapshots" i've always relied on a very simple solution. I take images of my root & boot partitions with "dd" so i can flash them back anytime i want and that's about it. I also do this rarely and on per need basis and i'd choose this over a copy-on-write solution anytime for my personal needs.
So I could potentially recover from "rm -rf /*" right?
Some of it. But that would delete your home directory too which isn't a part of the snapshot.
This is missing why snapshots aren't backups:
The data on the drive still only exist one time, so if the data on the drive corrupts, all files that point to that data will be corrupted. Rolling back to a snapshot won't help.
Matt, absolutely great . Thank You. But you speak about "data". Be careful, for me and I guess not only for me as "user", datas are primarely my openoffice files, my pictures... Difficult to distinguish between "user data" and "system data" or "root data".
can you make a video about luks?
May very well use BtrFS for my inbound Asustor 6 bay, but, only for an initial 10TBX2 mirror, and, replicated to another 10 TB drive in my WInblows system....; I watched most of the negatives regarding Btrfs, but, did anyone address the 'RAID 5/6-DO NOT RECOMMEND!' ? This is noteworthy for folks planning on larger arrays than RAID1 or 10...
I wonder how this interacts with wear levelling on ssds, it's a cool concept
Are you sure it doesn't roll off the tongue a little bit "butter"?
Matt on snap shots. It's better to have it and not need it than to need it and not have it. More on Arch btrfs please...
20:57 Hey! What did I ever do to you? 🤣
I would like to see you set up btrfs in arch please
Pay-offs and trade-offs really. The BTRFS with registered RAM is also a good way to have an array of disks (maybe 8) with extra indexing, if it is to be that then data can be repopulated where a disk is to be swapped out for a new one. The BTRFS has performance trade-offs so for some systems people prefer something else. It also depends if people want to do a bunch of the file-system's work in RAM and in what manner. So for instance, ZFS (similar in arrays of disks for BTRFS, here and there) for doing a lot of its work in RAM has the performance boost. However if RAM is to be used like a RAM-Disk, some of the Reiser File system approaches are good for performance (and then the RAM data is periodically written to a disk), and thereby differential data comparisons using cyclic polynomials are probably going to do a reasonably large amount of work on FPU (assuming CPU is the main data processor in that scenario). It would be a close call and sometimes beat EXT4. However even EXT3 _(with its performance penalties has some uses for simplicity such as its journaling)_ is easier to convert with EXT2 and that means a Linux system that will need to interact heavily with a BSD system can do so more easily). An example might be where (Super) CHROOT (jail) is used in place of a BSD-Jail when file-system privileges are all that is needed, and then that means that passthrough (like in a VM) is no longer requirement, thereby ditching the latency issues, even if the disks used end up not being so big or the EXT3 and EXT2 style slower performance is worth it so as to not have to incur penalty in performance with respect to that latency. In the scenarios whereby work is done in RAM, some people might not care about the slow performance of EXT2 and EXT3 or even if it is journaling at the moment whereby they save the state of a VM (if they are using one that is). Then there is no namespace issues for non-volatile memory in passthrough because they're not using passthrough for it anyway, just RAM. The exchange between BSD and linux thereby is probably going to be FreeBSD however, OpenBSD is sometimes used too such as if eschewing the desire for a desktop other than those rare moments when you might connect an OpenBSD rig to another OpenBSD rig (linked by a cable probably) just so both are the same and a known-quantity but you just want to do that one thing in a desktoppy way so a deciduous instance of a desktop in the OpenBSD 'client' is used for a moment to complete that task before getting rid of that desktop and going headless again. File-system usages in OpenBSD can end up meaning FAT32 gets used here and there when doing a one-off job to interact with another computer but the chances are it will be FreeBSD and then EXT2 _(thereby the conversion being easy between it and EXT3)_ linking to a linux box. Sometimes it is OpenBSD and for minimal scenarios (some reverse proxy rigs), one just can't beat it _(and you'd be remoting in by OpenSSH anyway or, for some other OS combinations converting between MIT-License PuTTYgen and OpenSSH SSH-keygen)._ It isn't just the setup security and stability combinations but the ratio between revenue for licencing solutions versus deployment solutions income. It means you have to think of what the guts of your system is to be made of _(registered RAM for instance, and how much RAM)_ and the file-system used and what it interacts with including system-calls of some other OS. NetBSD is an interesting one for embedded solutions when people will look elsewhere for their MIPS (say mipsel) support has been dropped in some Linux OS types. An upcoming reason why file-systems interacting with BSD (probably form Linux) will matter is for how, considering Linux does not understand the system calls of BSD, BSD in Jails has multiple socket listening. As an aside, a multiple BSD jails might be managed with Ansible.
My comment has no hate in it and I do no harm. I am not appalled or afraid, boasting or envying or complaining... Just saying. Psalms23: Giving thanks and praise to the Lord and peace and love. Also, I'd say Matthew6.
Btrfs also has other advantages over ext4. For example filesystem compression, reflinks and raid
Yeah, I know I didn't cover any of that.
BTRFS is trying to be what ZFS is, sure you have OpenZFS for Linux, but Linus has no plans to include that into the kernel. When are people going to look at filesystems for NAND/NVMe drives? the ext*, XFS, JFS, BTRFS is all well and good but those filesystems are made for conventional disks in mind. I don't know of any distro that has JFFS2 as an option. Slackware AFAIK is the only distro that allows you to install on a F2FS filesystem which is made from the ground up for such devices - granted you can't boot off of it you need a regular ext* filesystem, but i guess it is better than nothing. My point stands though, considering more and more users are now using SSD or NVMe drives, it is time more distros look at F2FS or JFFS2 , though that seems to be the only filesystems available for Linux.
@@Watcher4361 i guess this is the one time BSD is better, you can mix-and-match different licenses afaik , it has actual ZFS and not a re-implementation of ZFS
@@breadmoth6443At leastFreeBSD uses OpenZFS now.They migrated a couple years ago IIRC. Dunno about the other BSD variants.
“BetterFS” comes from the filesystem just being better than other filesystems. “ButterFS” is based on BTRFS using copy on write (COW) to enable atomic writes and snapshots. Butter comes from cows, so there you go. Both are used in everyday speech and they sound very similar to each other. Neither is wrong.
It seems as though btr is a more complicated version of timeshift from my "just works" mindset. If you aren't using something like timeshift I don't know what to tell you.
Garuda sets up Btrfs out of the box
So, inexperienced users or newbies should not use BTRFS unless they are using a distro that has already taken care of the necessary setup that takes advantage of snapshots. Other distros can use BTRFS, but require the user to be an experienced Linux user familiar with how BTRFS works in order to get it set up properly on any particular distro.
As you were describing how BTRFS copies-on-write, I was thinking that it would involve instabaility and take up space or cause fragmentation. It really does not take up space because the data would normally still be there anyway but not registered in a file system table. It sounds like you are saying that BTRFS maintains the MAIN files system pointers and additional file system pointers to files that have not been overwritten. Over time, trying to avoid overwriting files in order to maintain snapshot integrity, it sounds like it would cause fragmentation, unless the snapshots are occasinally defragmented and pushed to a given area of the drive. This fragmentation would cause the drive to be slower unless an auto-defrag is implemented. I guess I mean to say that the snapshots should be consolidated to a given area of the drive when the computer is not under heavy use in order to reduce fragmentation.
I would prefer to maintain my own snapshots on a sepatrate drive using TimeShift. I realize that this is not as elaborate as the copy-on-write BTRFS because I would only have a snapshot from the last time a snapshot was taken by TimeShift, which won't be every time a file changes. But I feel more comfortable knowing that my file system is not all jumbled up with snapshots integrated behind the scenes.
BTRFS does not really help if the drive fails, because, like you said, IT IS NOT A BACKUP. With TimeShift on a separate drive, you can basically get a fresh install of your OS back to normal by restoring a TImeShift snapshot and load a backup of your home directory.
BTRFS works great out of the box with Manjaro, and the AUR auto-snap and btrfs-grub-tools all work great.
No issues with it so far. Manjaro itself has done some odd things occasionally, but, at very least they're good about fixing it, and, I don't want to use linux without the AUR, complete non-starter otherwise, there is no greater collection of talent in the linux community.
Also, something you didn't mention is, snaps will bail you out if you make a bad config change that prevents the system from working properly. So it's not just updates/upgrades where it's useful.
Garuda Linux has excellent BTRFs.
👍🏻👍🏻👍🏻👍🏻👍🏻
Garuda also uses brtfs by default as well.