Even if he's a hater, I'm pinning this because I know it's going to come up a lot in the comments. RoW stands for Redirect on Write, it is called that because instead of making a full copy of the data, it just copies the change and points to the old data. TRUE CoW (Copy-on-Write) isn't used because it's wasteful compared to RoW, and yes, BTRFS and ZFS are RoW. RoW is part of the CoW family, like Sprite is a soda.
I think its a good clarification because COW is misunderstood. ROW is not inherently slower, there is no extra write load, writes are just not in place. What fundamentally makes btrfs a bit slower is maintaining more complex metadata including checksums. Keeping alot of snapshots (dozens) can make btrfs noticably slow, because their metadata has to be co-ordinated, but a few daily & weekly & monthly can be kept for accidental deletions, very efficiently without slowdown. For me thats the most useful thing besides the whole system rollback capability.
@@adymodeinteresting comment. Well, I have a Nas on XFS and I wonder if I should take the data partition and format them to btrfs. I see that you know well this filesystem and I want to have an external opinion about this. To be more precise, the data partition is a software RAID in mirroring of 8TB
@@xabi08 I haven't used XFS, maybe it is not worth switching, but BTRFS seems preferable to be going on with. It is simple to configure, its been solid and power/crash resistant for years, (except for raid5/6 which is still experimental). The snapshot ability works like a dream and is easy to schedule with an app like "timeshift". Just don't build up loads of snapshots if high performance is important. Compression also works very nicely and is simple to turn on/off. Autodefrag works well. It is being very actively maintained and improved by quality kernel developers in recent years. I bet if anything supercedes EXT4 as default it will be BTRFS, so its good to go with. On the other hand if the XFS setup is satisfactory it may not be worth the hassle to migrate. Maybe wait to try btrfs for the next fresh linux system install.
@@xabi08 Well, I have a Nas on XFS and I wonder if I should take the data partition and format them to btrfs. - BTRFS raid is broken, period. Please don't repeat my mistake. You will regret it. Use ZFS instead. ZFS work well to protect against HDD bit rot. For SSD raid you can continue with XFS or use BTRFS over Linux raid. I haven't seen ZFS checksum errors on SSDs, not a single case during 8 years of using old SSDs. It doesn't look like bit rot is a concern for SSDs.
Btrfs and ZFS support transparent compression. It's very well integrated into both, just turn it on. Btrfs even has multiple implementations with different algorithms, and you can set the compression level.
THANK YOU, long wanted to know what btrfs does different. Such a good video, Thank you!
Місяць тому+6
For me a real advantage of BTRFS is an ability to detect data corruption - it's even more important to know which file version is correct because it's much easier to automatize whole process of restoring data, it's content agnostic, I don't need specialized tools to verify files one-by-one. And this feature connects flawlessly with redundant storage support.
The biggest issue I have with btrfs is that distros and DEs basically don't do anything with it. Except for opensuse. Fedora creates subvolumes for @home and @root and that's basically about it (there is a new btrfs sig). No snapshots or automatic scrubs/balances of any kind and if there is checksum error you'll likely not notice it until something goes wrong or you actively look for these kinds of issues in the logs. A dedicated GUI app for the desktop would fix these issues imo. Also what I think should be talked about more are snapshots for your home directory. It saved my ass quite a few times having an old copy of some file around. Anyway this is a really good video explaining linux filesystems.
I formatted all my drives to BTRFS on my desktop for one reason, windows support. I dualboot and having an FS that works perfectly on windows *and* linux is something that can't be understated.
compression is the reason that I like BTRFS, and in some scenarios, that makes not only more space, but also read and writes where the bottleneck is the connection with the drive or the drive itself. and of course, zstd is great!
had to play at 1,25x as it was too slow for my preference. anyway, well explained, didn't really expect a small channel like this to make such a good video, tbh. I'm running Pop OS with btrfs on my laptop, manually configured it like that as ext4 is the default for the distro, but didn't really understand btrfs, even after reading about it, except that it's supposed to be better for protecting against dataloss. you explained it well
Waiting for BcacheFS video. Watched some of the older videos and can say this - you sound better and better with each video. There's still a lot of room to grow but your progress in just 2 month is really fast. I also personally enjoy topics you cover, especially more technical ones like this one and one about the kernel. Good luck in the future.
BTRFS is the default for Fedora installs and also does rectos support BTRFS which should be default cuz it can't be bricked by failed writes like when ros bsods.
You forgot to mention: You can disable copy-on-write on the whole btrfs filesxstem or only on individual files (needed for swap for example). Also Gentoo is not unstable or bleeding-edge by default. It is something between Fedora and Ubuntu.
oh wow, you mentioned BcacheFS at the end and now I want to jump ship from btrfs to bcacheFS xD. Actually using btrfs in one of my laptops, and I'm using a convoluted system for caching a MicroSD with the computers SSD using LVM cache, its a mess, and in the end the space used for cache is just for cache and nothing else, bcacheFS, unsurprisingly, supports bcache, which would just be miles better than what I have going on, looking forward to that video!
From experience, I've experienced BTRFS going RO on my Kinoite installation randomly with no real easy way to recover it only last week. I had to wipe clean, reinstall kinoite (and reformat to ext4 just in case) to get a working system back. Yes, a filesystem that yells at you if something went wrong is preferable, but i'd much prefer if that something didn't went wrong in the first place.
Thanks for your video. Tbh, i did not know what btrfs was, but thanks to your vid, i discovered something very useful and i finally know why my linux distro formatted my home partition with btrfs
my go to fs setup is snapraid on btrfs. each disk gets its own btrfs partition, and even on a single disk, I use partitions over subvolumes because it's easier to restore or nuke if needed. (and filling up /home won't prevent the system from booting like it can if you have subvolumes with dynamic sizes) and snapraid because you don't have the cost of raid5/6, and it's easy to restore as it basically works like a regular backup, if you lose more than one disk on a raid 5 you still have the rest of the data. though the caveat is that you need to schedule the synchronization because it works like a backup. if you have a system that works in bursts it's great. also you can host it on a slow system that's just enough to handle the disk and network and do the sync on a fast system.
I just use BTRFS for the data integrity. I'm sure it's slower than EXT4 but I am none the wiser and my data is a little safer. Planning a build that may need ZFS for its RAID features.
I just successfully got my ZFS pool mounted again after a month by mounting it in a VM with excessive virtual memory backed by a file. Over two terabytes written to my poor SSD, but it WORKED
For me it was over 6 months with btrfs.fsck and it had about700G including swap. It ended with an out of memory error. The metadata was only 256GB. This was of course a decade ago. We already switched to xfs or ext4. *if* btrfs would have worked, it would have been so awesome for a incremental backups with rsync. But yeah, it was very unstable. We tried it at other places for for instance object storage, as it would be able to do scrubbing. But scrubbing didn't help with auto-corruption. I am waiting for massive heavy I/O bound installations to report it is stable before venturing into btrfs again for anything. I probably will be using bcachefs before I trust btrfs. ZFS is something I won't even try... It already uses a lot of memory without doing anything.
to be clear: we hit enough ext4 bugs when it was considered stable... But it never lead to data loss, only to a hanging filesystem, which we could escape by echo b > /proc/sysrq-trigger . ext4 had a number of issues with tight memory in a memory namespace. It would lock the entire filesystem over all namespaces.
My only complaint is referring to snapshot's as backups. Depending on FS they can be used to replicate changes over a network for backups but they allow rollback (which is still awesome), not backups. Other than that solid overview, while I personally prefer ZFS I've been keeping an eye on BTRFS and Bcachefs as well.
18:00 very controversial... why does the "system" (/) require a higher performance than the "data" (/home)? I mean, system is loaded into RAM almost completely when booting, then occasionally it's read when starting apps. While data is manipulated (both read and written) constantly. System could be basically read-only except /var. Also, snapshotting the data is fine but if that hinders performance 2 times it would be better just to backup it (copy to a different media) and then work at full speed. I can't imagine currently a usage scenario when data performance is less important than system. At least for the following the data performance is much more important, and the system could as well be in a squashfs mounted from a flash drive, with an overlay in some scratch space. * code writing and compiling - (data is much more important, the compiler will be in cache) * multimedia (pictures/video/audio) * vector data (svg/3d models/...) * databases, ML * gaming (the Steam library is in ~/.local/share/Steam; doesn't apply to games from the distributive itself, but they are so tiny usually that their data doesn't matter) The data is almost irrelevant (because there are few reads and writes) for * internet browsing and * working with plain text (without embedded images). System disk speed is irrelevant in these cases too though.
I agree with most of what is written. The way i see it, there is no value to snapshot(or any btrfs features) of the *system, so we shouldn't put it on BTRFS. I agree that data in a lot of cases has more to benefit from faster read/write than system, but if you value your data and would like your fs to do snapshots... than the mix I propose is good! And yes, a standard backup on ext4 will do the same for most people while keeping the fast speed but will take more space than snapshots (;
@@Maple-Circuit I'd say there is no sense in backing up system, as it could be easily reinstalled. But snapshotting system before updates could save a lot of time.
9:32 I wrote an article many years ago about this specific subject and why NTFS is so much better than EXT. There are always unearthed/bad administrators saying: "it's your own fault, should have made backups". Reality is that people make mistakes and overlook details, and this is where NTFS made so much more sense in SOHO situations. Accidentally deleted a file? Most of the time we can get it back. I really hope BTRFS can close the gap with NTFS.
It won't. In fact btrfs has async discard enabled by default. I.e. it issues the fstrim command automatically for deleted files. Which makes it very unlikely to restore anything on SSD.
Directly benchmarking DRAM or storage or how it's managed will always show a drastically larger difference than benchmarking applications running on each. I'm curious if maximum or otherwise optimal compression on btrfs causes annoyances in the performance of anything.
Stupid but valid question: I will be building a Minecraft server machine soon. So Minecraft is huge on write speed, it is performant depending largely on that if no CPU bottleneck exists. So theoretically the dumbest yet best setup for breakneck Minecraft server speed would be... ZSH? According to your video. Right? lol.
Not stupid! For a simple Minecraft server, don't overcomplicate it. You should go with EXT4 as it is stable, simple and fast. Extra tips: use a SSD for you hard drive, small one (128gb is enough for minecraft server) cost nothing and will do a world of difference in performance. also don't overcomplicate your distro choice, go with what you know or something like Ubuntu (you can use the standard version if you want an interface). Have fun gaming!
@@Maple-Circuit I second this: If you want a very fast and trustworthy filesystem, always go for ext4. Any other file system will take so much resources that it will bog down the whole system. ext4 is very smart in writing and will use delayed allocation. Exactly the thing needed for reiser4 to be included into the kernel.
I am quite sure you mixed up stuff in the CoW and journaling section. Also ext4 is (unless manually diabled) a journaling filesystem, so your statement at 9:43 might be not correct.
I've been thinking about using btrfa instead of EXT4 for on my opensuse tumbleweed installation. But the thing that i'm mostly concerned about is SSD writes count. As far as i know each SSD drive has something named TPW and using CoW will increase the write count and then, decrease SSD lifespan Is it really true? Does it have any significant effect on my SSD lifespan? Beside that, i know that even when CoW is disabled, using snapshots is possible. My question is, how? Is it really possible? Because it seems like the whole snapshot thing is based on having a copy and CoW does that( i guess)
SSD write were a problem 7 years ago, but now it's not an issue anymore. You could write your SSD full speed for a year and it would still be alive and well (;
@@Maple-Circuit thanks for the response! Do you know anything about my second question? Why would snapshots work without CoW. And if CoW is not necessarily needed, then why even use it? What advantage does it provide? And to be honest, i don't really want to tinker my filesystem. So do you think it's wiser to use all ext4 on opensuse? I've seen people saying that a great advantage of opensuse is its btrfs config, but as i said, i think i would be fine with something simple like ext4
@@Kasra513 if BTRFS is mounted with NOCOW from the start, there is no snapshot possible, i belive that if you have already existing snapshot and then enable NOCOW you would keep the already existing snapshot... i think (; If you don't need all performance down to the smallest % you should use BTRFS with opensuse, not only is the implementation well done, but the added security from the checksums gives you yet another way not to lose your data.. which is fun (;
zfs has it's usecases also it's not completle true that's it's resource hog. It's decision to cache to ram was rigth at time when fast nvme ssds weren't existent. I have used zfs on freebsd and linux. While I agree it takes a bit more resources on linux it's nothing scary and in fact i use it as filesystem of choice. Maybe that's because of all tooling around zfs that has been developed and makes life easier. And also it's mature and rock solid can't be said same for btrfs which for years for example is missing stable support for raid56(not important for home user but..)
It has "btrfs scrub" which checks not only filesystem errors but also data integrity using checksums. edit I typed too soon! after reading into it, scrub doesn't do much structural checking. But "btrfs check" is the command for that, it is even aliased as "btrfsck"
@@AllanSavolainen btrfs scrub is better than fsck - it checks filesystem and data integrity. btrfs is the default filesystem today on widely used distros.
The point of btrfs is partly that fsck is unnecessary. The CoW and checksums combine to make the functionality of traditional fsck unnecessary. Btrfs does have the scrub functionality mentioned by another commenter, and I think there is a repair option, but if you are looking for the repair tool, you should probably be looking at how to restore from a backup in parallel with the repair attempt.
@@yramagicman675 Which is why I cannot use btrfs. I know these filesystems have all kinds of journals etc to handle crashes and power failures. But I still require a filesystem to have working fsck tool that can repair corrupted filesystem into semi-working state. Prefer to be able to get todays files safe even if I have to restore a backup.
At around 13 minutes you are using a SQLite to compare speeds. I expect that is because traditional SQL servers would use RAM as caching? I am using SQLite as my main database and ran into some "file is being written to" issues on windows. I managed to resolve them. (Everybody is a Server unless somebody else has written that info to the db before) I definitely have less than 10000 queries per minute from multiple clients. It doesn't feel like it is worth the effort to have "an official database" in our SQL Server. Am I wrong? There is nothing wrong I'm not even worried about adding 20 more clients. It seems SQLite is pretty good at handling my work loads.
I'm not sure I understand your comment correctly, but yes, in production, your sql server will cache and time write and read. This test is there to show the limits of the filesystem. In normal operation, most SQL servers are optimized for EXT4 style FS and will have multiple optimization to work better with EXT4
Why would you want to use sqlite as a real production server that serves many people? Real question, I cannot see why you would do that unless maybe you run on a raspberry pie or something else that can't run a more robust DB.
Honestly I am way too lazy to figure out fancy features of filesystems. In my time of distro hopping, XFS felt the fastest (for example when booting) which is why I use it. Havent had any issues but even if I do that's fine since I dont use /home for my files. IMO the best way to use partitions is to disregard partitions made and used by software for personal files since /home will inevitably get drowned in junk (at least that what always happens to me).
Snapshot is used for backup by 99% of Snapshot users. Snapshot exists for more than backups, but that is its primary use. Does a small, meaningless correction make you feel superior?
@@Maple-Circuit No they are not. Snapshots revert modifications in time, they do nothing to protect against partition or disk failure. That's why they are useful for system partition quickly reverting updates that went south. For critical/personal data in your home directory, on the other hand, you will need back-up to external storage. You could use btrfs or rsync on your external drive; the first write will be a full back-up full duplication of your data. Using btrfs snapshots within your home partition can still be useful, e.g. accidental file removal. Yet it's not a back-up because there's just one copy of the data, which, once corrupted, cannot be restored
@@Maple-Circuitwhere do 99% come from? Your friends and family? No competent admin will "use" snapshots for backups. "Using snapshots for backups" is like "using no backups for backups", or a variation "use raid for backups". As an analogue, normally you can't substitute arm for leg. It could be a part of a trick, or a workaround for impaired ones, but even then no one will say that a footless man's legs grow from shoulders. Same with backups: you could have no backups, and try substituting them with snapshots, but that's an impairment, and shouldn't be called backups. And the consequences are also daring.
@@FlyWR I disagree. A snapshot might not be a backup to be used in the sense of disk failure or the house burning down, it's meant to be used when human or software error happened. From my perspective it's still a backup, it's a less safe one, but it can run more frequently. I often use "Previous Versions" or the "Shadow Copies" on windows NTFS drives to get some file or folder back from yesterday or last week. It's the "snapshot" of the Windows world for about 20+ years. It's very handy, because this "backup" is right there, with a single click of a button. It comes in handy if you made a mistake like deleting the wrong files and not using the recycle bin e.g.. This does not mean I don't have 2 other backups on a different drive and site. I normally don't need to recover from these backups, it is also inconvenient to do so, so I really like the option to have this less safe backup at hand. It can also help if your regular backup schedule is once a day or week, but snaphots and "Previous Versions" can be created every 4 hours or so, which is nice. Another point: On Windows at least, you can also have the "Previous Verisons" or snapshot data be written to another disk / location. In that case, there really is no argument about a snapshot not being a backup anymore.
@@Maple-Circuit It's a troll I guess. o) Even if your statement would be wrong (which I think is not the case), the user comment above is not appropriate and looks not very polite to me. Maybe he had a bad day and lost control for a moment, it can happen to humans, it should not, but it happens.. o)
Pretty sure this is a myth that comes from misinterpreting the popular advice that you aren't making full use of ZFS data integrity without ECC. Doesn't mean ZFS is worse compared to OTHER filesystems, in fact it is better.
B Tree File System is still not stable. IEven the engineers who develop it say so, and do NOT convert in place an extra file system to a birds unless you like playing Russian roulette. Data Destroyer. One just needs to be aware of the limitations before willy billy launching into using birds. On the other hand, ZFS is rock-stable.
Correction, BTRFS is stable. In-place upgrade is not and can never be stable. You must be looking at a very old comment to think that BTRFS isn't stable, since it is used in production and is the default in many distros.
What??? Linux-based systems certainly so use Zettabyte File System despite it not "being in the kernel." The narrator should have corrected his scriptwriter, because that person doesn't understand that ZFS does not need to be "in" a Linux kernel. 😮
Narrator and scriptwriter are the same. And yes, there have been implementations of ZFS on Linux. but you have to admit that if its not in the kernel, there is no widespread use of it!
It's a ROW, not a COW.
Even if he's a hater, I'm pinning this because I know it's going to come up a lot in the comments.
RoW stands for Redirect on Write, it is called that because instead of making a full copy of the data, it just copies the change and points to the old data.
TRUE CoW (Copy-on-Write) isn't used because it's wasteful compared to RoW, and yes, BTRFS and ZFS are RoW.
RoW is part of the CoW family, like Sprite is a soda.
I think its a good clarification because COW is misunderstood. ROW is not inherently slower, there is no extra write load, writes are just not in place. What fundamentally makes btrfs a bit slower is maintaining more complex metadata including checksums. Keeping alot of snapshots (dozens) can make btrfs noticably slow, because their metadata has to be co-ordinated, but a few daily & weekly & monthly can be kept for accidental deletions, very efficiently without slowdown. For me thats the most useful thing besides the whole system rollback capability.
@@adymodeinteresting comment. Well, I have a Nas on XFS and I wonder if I should take the data partition and format them to btrfs. I see that you know well this filesystem and I want to have an external opinion about this. To be more precise, the data partition is a software RAID in mirroring of 8TB
@@xabi08 I haven't used XFS, maybe it is not worth switching, but BTRFS seems preferable to be going on with. It is simple to configure, its been solid and power/crash resistant for years, (except for raid5/6 which is still experimental). The snapshot ability works like a dream and is easy to schedule with an app like "timeshift". Just don't build up loads of snapshots if high performance is important. Compression also works very nicely and is simple to turn on/off. Autodefrag works well. It is being very actively maintained and improved by quality kernel developers in recent years. I bet if anything supercedes EXT4 as default it will be BTRFS, so its good to go with. On the other hand if the XFS setup is satisfactory it may not be worth the hassle to migrate. Maybe wait to try btrfs for the next fresh linux system install.
@@xabi08 Well, I have a Nas on XFS and I wonder if I should take the data partition and format them to btrfs.
- BTRFS raid is broken, period. Please don't repeat my mistake. You will regret it. Use ZFS instead. ZFS work well to protect against HDD bit rot.
For SSD raid you can continue with XFS or use BTRFS over Linux raid. I haven't seen ZFS checksum errors on SSDs, not a single case during 8 years of using old SSDs. It doesn't look like bit rot is a concern for SSDs.
I hope bcachefs' performance will soon eclipse btrfs. I really like compression support in filesystems
Btrfs and ZFS support transparent compression. It's very well integrated into both, just turn it on. Btrfs even has multiple implementations with different algorithms, and you can set the compression level.
@@slim5782 I've just gotten gentoo working on a multi device bcachefs filesystem
We'll see how it goes
@@OfficialViperTrue, fedora has compression out of the box
I discovered you through the 6.10 kernel video. This channel is really ✨cozy✨ compared to other Linux content ☕Thank you💚
THANK YOU, long wanted to know what btrfs does different. Such a good video, Thank you!
For me a real advantage of BTRFS is an ability to detect data corruption - it's even more important to know which file version is correct because it's much easier to automatize whole process of restoring data, it's content agnostic, I don't need specialized tools to verify files one-by-one. And this feature connects flawlessly with redundant storage support.
I am having a good time using BTRFS in bluefin, its nice to start to understand what i am using, thanks for the video.
actually more comprehensive then the other videos
THX!
I have only btrfs on my disks not just because of features you've mentioned but also one you didn't: subvolumes
Not having to worry about how much memory to allocate for each subvolume is really cool.
The biggest issue I have with btrfs is that distros and DEs basically don't do anything with it.
Except for opensuse.
Fedora creates subvolumes for @home and @root and that's basically about it (there is a new btrfs sig).
No snapshots or automatic scrubs/balances of any kind and if there is checksum error you'll likely not notice it until something goes wrong or you actively look for these kinds of issues in the logs.
A dedicated GUI app for the desktop would fix these issues imo.
Also what I think should be talked about more are snapshots for your home directory.
It saved my ass quite a few times having an old copy of some file around.
Anyway this is a really good video explaining linux filesystems.
100% TRUE!
I formatted all my drives to BTRFS on my desktop for one reason, windows support. I dualboot and having an FS that works perfectly on windows *and* linux is something that can't be understated.
Leaving a comment for the YT algorithm.
Your videos are amazing. Keep them coming and we'll gladly support you!
Thanks!
THX!
compression is the reason that I like BTRFS, and in some scenarios, that makes not only more space, but also read and writes where the bottleneck is the connection with the drive or the drive itself. and of course, zstd is great!
had to play at 1,25x as it was too slow for my preference. anyway, well explained, didn't really expect a small channel like this to make such a good video, tbh. I'm running Pop OS with btrfs on my laptop, manually configured it like that as ext4 is the default for the distro, but didn't really understand btrfs, even after reading about it, except that it's supposed to be better for protecting against dataloss. you explained it well
Great video.
Please now in deph video about Brfs usage.
Also same for Bcachefs and zfs.
Thanks
BTRFS best feature is ability to combine multiple disks into one filesystem without need of LVM.
Waiting for BcacheFS video.
Watched some of the older videos and can say this - you sound better and better with each video. There's still a lot of room to grow but your progress in just 2 month is really fast. I also personally enjoy topics you cover, especially more technical ones like this one and one about the kernel.
Good luck in the future.
BTRFS is the default for Fedora installs and also does rectos support BTRFS which should be default cuz it can't be bricked by failed writes like when ros bsods.
You forgot to mention: You can disable copy-on-write on the whole btrfs filesxstem or only on individual files (needed for swap for example). Also Gentoo is not unstable or bleeding-edge by default. It is something between Fedora and Ubuntu.
oh wow, you mentioned BcacheFS at the end and now I want to jump ship from btrfs to bcacheFS xD.
Actually using btrfs in one of my laptops, and I'm using a convoluted system for caching a MicroSD with the computers SSD using LVM cache, its a mess, and in the end the space used for cache is just for cache and nothing else, bcacheFS, unsurprisingly, supports bcache, which would just be miles better than what I have going on, looking forward to that video!
From experience, I've experienced BTRFS going RO on my Kinoite installation randomly with no real easy way to recover it only last week. I had to wipe clean, reinstall kinoite (and reformat to ext4 just in case) to get a working system back.
Yes, a filesystem that yells at you if something went wrong is preferable, but i'd much prefer if that something didn't went wrong in the first place.
Thanks for your video. Tbh, i did not know what btrfs was, but thanks to your vid, i discovered something very useful and i finally know why my linux distro formatted my home partition with btrfs
This channel is such a gem
Pure gold!
I decided to use it even with all the hate comment about it on my NAS. The snapshot are so useful. No problem so far, crazy performance with SSD.
damn weirdly timed video, was considering doing my next linux box in btrfs when I saw your vid on the feed XD
my go to fs setup is snapraid on btrfs.
each disk gets its own btrfs partition, and even on a single disk, I use partitions over subvolumes because it's easier to restore or nuke if needed. (and filling up /home won't prevent the system from booting like it can if you have subvolumes with dynamic sizes)
and snapraid because you don't have the cost of raid5/6, and it's easy to restore as it basically works like a regular backup, if you lose more than one disk on a raid 5 you still have the rest of the data.
though the caveat is that you need to schedule the synchronization because it works like a backup.
if you have a system that works in bursts it's great.
also you can host it on a slow system that's just enough to handle the disk and network and do the sync on a fast system.
I just use BTRFS for the data integrity. I'm sure it's slower than EXT4 but I am none the wiser and my data is a little safer. Planning a build that may need ZFS for its RAID features.
With data journal ext4 can also survive crashes in the midst of a write, but of course that's a perf sucker.
I just successfully got my ZFS pool mounted again after a month by mounting it in a VM with excessive virtual memory backed by a file.
Over two terabytes written to my poor SSD, but it WORKED
ZFS is No pain No gain: The filesystem XD
For me it was over 6 months with btrfs.fsck and it had about700G including swap. It ended with an out of memory error.
The metadata was only 256GB.
This was of course a decade ago. We already switched to xfs or ext4.
*if* btrfs would have worked, it would have been so awesome for a incremental backups with rsync.
But yeah, it was very unstable.
We tried it at other places for for instance object storage, as it would be able to do scrubbing. But scrubbing didn't help with auto-corruption.
I am waiting for massive heavy I/O bound installations to report it is stable before venturing into btrfs again for anything.
I probably will be using bcachefs before I trust btrfs.
ZFS is something I won't even try... It already uses a lot of memory without doing anything.
to be clear: we hit enough ext4 bugs when it was considered stable... But it never lead to data loss, only to a hanging filesystem, which we could escape by echo b > /proc/sysrq-trigger .
ext4 had a number of issues with tight memory in a memory namespace. It would lock the entire filesystem over all namespaces.
next do xfs i really like xfs
will do but i've got some vids already lined up... soon!
an insight to RAID would be cool
My only complaint is referring to snapshot's as backups. Depending on FS they can be used to replicate changes over a network for backups but they allow rollback (which is still awesome), not backups. Other than that solid overview, while I personally prefer ZFS I've been keeping an eye on BTRFS and Bcachefs as well.
100% True!
The only thing in the IT world besides zstd that I can say I am a fanboy of.
18:00 very controversial... why does the "system" (/) require a higher performance than the "data" (/home)? I mean, system is loaded into RAM almost completely when booting, then occasionally it's read when starting apps. While data is manipulated (both read and written) constantly. System could be basically read-only except /var. Also, snapshotting the data is fine but if that hinders performance 2 times it would be better just to backup it (copy to a different media) and then work at full speed.
I can't imagine currently a usage scenario when data performance is less important than system. At least for the following the data performance is much more important, and the system could as well be in a squashfs mounted from a flash drive, with an overlay in some scratch space.
* code writing and compiling - (data is much more important, the compiler will be in cache)
* multimedia (pictures/video/audio)
* vector data (svg/3d models/...)
* databases, ML
* gaming (the Steam library is in ~/.local/share/Steam; doesn't apply to games from the distributive itself, but they are so tiny usually that their data doesn't matter)
The data is almost irrelevant (because there are few reads and writes) for
* internet browsing
and
* working with plain text (without embedded images).
System disk speed is irrelevant in these cases too though.
I agree with most of what is written.
The way i see it, there is no value to snapshot(or any btrfs features) of the *system, so we shouldn't put it on BTRFS.
I agree that data in a lot of cases has more to benefit from faster read/write than system, but if you value your data and would like your fs to do snapshots... than the mix I propose is good!
And yes, a standard backup on ext4 will do the same for most people while keeping the fast speed but will take more space than snapshots (;
@@Maple-Circuit I'd say there is no sense in backing up system, as it could be easily reinstalled. But snapshotting system before updates could save a lot of time.
9:32 I wrote an article many years ago about this specific subject and why NTFS is so much better than EXT. There are always unearthed/bad administrators saying: "it's your own fault, should have made backups". Reality is that people make mistakes and overlook details, and this is where NTFS made so much more sense in SOHO situations. Accidentally deleted a file? Most of the time we can get it back. I really hope BTRFS can close the gap with NTFS.
It won't. In fact btrfs has async discard enabled by default. I.e. it issues the fstrim command automatically for deleted files. Which makes it very unlikely to restore anything on SSD.
Nice video!
Maybe you will make a video about XFS?
Yep!
Directly benchmarking DRAM or storage or how it's managed will always show a drastically larger difference than benchmarking applications running on each. I'm curious if maximum or otherwise optimal compression on btrfs causes annoyances in the performance of anything.
Stupid but valid question: I will be building a Minecraft server machine soon. So Minecraft is huge on write speed, it is performant depending largely on that if no CPU bottleneck exists. So theoretically the dumbest yet best setup for breakneck Minecraft server speed would be... ZSH? According to your video. Right? lol.
Not stupid! For a simple Minecraft server, don't overcomplicate it. You should go with EXT4 as it is stable, simple and fast. Extra tips: use a SSD for you hard drive, small one (128gb is enough for minecraft server) cost nothing and will do a world of difference in performance. also don't overcomplicate your distro choice, go with what you know or something like Ubuntu (you can use the standard version if you want an interface). Have fun gaming!
@@Maple-Circuit I second this: If you want a very fast and trustworthy filesystem, always go for ext4.
Any other file system will take so much resources that it will bog down the whole system.
ext4 is very smart in writing and will use delayed allocation. Exactly the thing needed for reiser4 to be included into the kernel.
I am quite sure you mixed up stuff in the CoW and journaling section.
Also ext4 is (unless manually diabled) a journaling filesystem, so your statement at 9:43 might be not correct.
I'm just bad at explaining, but yes, ext4 has a journal. It doesn't protect in case of power cut in the middle of a write, the CoW of BTRFS does!
I used btrfs as shared partition for both linux and windows but windows driver for it broke entire filesystem.
I hope the devs fix raid 5 and raid 6, then I would move my server from zfs to btrfs.
I think we are going to have BcacheFS stable before that XD
I've been thinking about using btrfa instead of EXT4 for on my opensuse tumbleweed installation. But the thing that i'm mostly concerned about is SSD writes count. As far as i know each SSD drive has something named TPW and using CoW will increase the write count and then, decrease SSD lifespan
Is it really true? Does it have any significant effect on my SSD lifespan?
Beside that, i know that even when CoW is disabled, using snapshots is possible. My question is, how? Is it really possible? Because it seems like the whole snapshot thing is based on having a copy and CoW does that( i guess)
SSD write were a problem 7 years ago, but now it's not an issue anymore. You could write your SSD full speed for a year and it would still be alive and well (;
@@Maple-Circuit thanks for the response!
Do you know anything about my second question? Why would snapshots work without CoW. And if CoW is not necessarily needed, then why even use it? What advantage does it provide?
And to be honest, i don't really want to tinker my filesystem. So do you think it's wiser to use all ext4 on opensuse? I've seen people saying that a great advantage of opensuse is its btrfs config, but as i said, i think i would be fine with something simple like ext4
@@Kasra513 if BTRFS is mounted with NOCOW from the start, there is no snapshot possible, i belive that if you have already existing snapshot and then enable NOCOW you would keep the already existing snapshot... i think (;
If you don't need all performance down to the smallest % you should use BTRFS with opensuse, not only is the implementation well done, but the added security from the checksums gives you yet another way not to lose your data.. which is fun (;
zfs has it's usecases also it's not completle true that's it's resource hog. It's decision to cache to ram was rigth at time when fast nvme ssds weren't existent.
I have used zfs on freebsd and linux. While I agree it takes a bit more resources on linux it's nothing scary and in fact i use it as filesystem of choice. Maybe that's because of all tooling around zfs that has been developed and makes life easier.
And also it's mature and rock solid can't be said same for btrfs which for years for example is missing stable support for raid56(not important for home user but..)
Do people not call it butter fs..?
Butter, better and BTRFS (;
Does btrfs have fully working fsck? I recall that has been my major point of not even testing it.
It has "btrfs scrub" which checks not only filesystem errors but also data integrity using checksums.
edit
I typed too soon! after reading into it, scrub doesn't do much structural checking. But "btrfs check" is the command for that, it is even aliased as "btrfsck"
@@adymode so the answer still is no, well, maybe someday it is usable
@@AllanSavolainen btrfs scrub is better than fsck - it checks filesystem and data integrity. btrfs is the default filesystem today on widely used distros.
The point of btrfs is partly that fsck is unnecessary. The CoW and checksums combine to make the functionality of traditional fsck unnecessary. Btrfs does have the scrub functionality mentioned by another commenter, and I think there is a repair option, but if you are looking for the repair tool, you should probably be looking at how to restore from a backup in parallel with the repair attempt.
@@yramagicman675 Which is why I cannot use btrfs. I know these filesystems have all kinds of journals etc to handle crashes and power failures. But I still require a filesystem to have working fsck tool that can repair corrupted filesystem into semi-working state. Prefer to be able to get todays files safe even if I have to restore a backup.
At around 13 minutes you are using a SQLite to compare speeds. I expect that is because traditional SQL servers would use RAM as caching? I am using SQLite as my main database and ran into some "file is being written to" issues on windows. I managed to resolve them. (Everybody is a Server unless somebody else has written that info to the db before) I definitely have less than 10000 queries per minute from multiple clients. It doesn't feel like it is worth the effort to have "an official database" in our SQL Server. Am I wrong?
There is nothing wrong I'm not even worried about adding 20 more clients. It seems SQLite is pretty good at handling my work loads.
I'm not sure I understand your comment correctly, but yes, in production, your sql server will cache and time write and read. This test is there to show the limits of the filesystem.
In normal operation, most SQL servers are optimized for EXT4 style FS and will have multiple optimization to work better with EXT4
Why would you want to use sqlite as a real production server that serves many people? Real question, I cannot see why you would do that unless maybe you run on a raspberry pie or something else that can't run a more robust DB.
Honestly I am way too lazy to figure out fancy features of filesystems. In my time of distro hopping, XFS felt the fastest (for example when booting) which is why I use it. Havent had any issues but even if I do that's fine since I dont use /home for my files. IMO the best way to use partitions is to disregard partitions made and used by software for personal files since /home will inevitably get drowned in junk (at least that what always happens to me).
its actually supposed to be pronounced "better fs"
BTRFS or Butter-FS or BetterFS or B-Tree-FS... you choose (;
i care about math and trees :(
Lol, maybe one day I'll be crazy enough to delve into the implementation details of a FS (;
Snapshots are NOT backups. Oh, my goodness. This man doesn't understand this file system.
Snapshot is used for backup by 99% of Snapshot users. Snapshot exists for more than backups, but that is its primary use.
Does a small, meaningless correction make you feel superior?
@@Maple-Circuit No they are not. Snapshots revert modifications in time, they do nothing to protect against partition or disk failure. That's why they are useful for system partition quickly reverting updates that went south. For critical/personal data in your home directory, on the other hand, you will need back-up to external storage. You could use btrfs or rsync on your external drive; the first write will be a full back-up full duplication of your data. Using btrfs snapshots within your home partition can still be useful, e.g. accidental file removal. Yet it's not a back-up because there's just one copy of the data, which, once corrupted, cannot be restored
@@Maple-Circuitwhere do 99% come from? Your friends and family?
No competent admin will "use" snapshots for backups. "Using snapshots for backups" is like "using no backups for backups", or a variation "use raid for backups". As an analogue, normally you can't substitute arm for leg. It could be a part of a trick, or a workaround for impaired ones, but even then no one will say that a footless man's legs grow from shoulders.
Same with backups: you could have no backups, and try substituting them with snapshots, but that's an impairment, and shouldn't be called backups. And the consequences are also daring.
@@FlyWR I disagree. A snapshot might not be a backup to be used in the sense of disk failure or the house burning down, it's meant to be used when human or software error happened. From my perspective it's still a backup, it's a less safe one, but it can run more frequently. I often use "Previous Versions" or the "Shadow Copies" on windows NTFS drives to get some file or folder back from yesterday or last week. It's the "snapshot" of the Windows world for about 20+ years. It's very handy, because this "backup" is right there, with a single click of a button. It comes in handy if you made a mistake like deleting the wrong files and not using the recycle bin e.g..
This does not mean I don't have 2 other backups on a different drive and site. I normally don't need to recover from these backups, it is also inconvenient to do so, so I really like the option to have this less safe backup at hand. It can also help if your regular backup schedule is once a day or week, but snaphots and "Previous Versions" can be created every 4 hours or so, which is nice.
Another point: On Windows at least, you can also have the "Previous Verisons" or snapshot data be written to another disk / location. In that case, there really is no argument about a snapshot not being a backup anymore.
@@Maple-Circuit It's a troll I guess. o) Even if your statement would be wrong (which I think is not the case), the user comment above is not appropriate and looks not very polite to me. Maybe he had a bad day and lost control for a moment, it can happen to humans, it should not, but it happens.. o)
How to pronounce it?
BTRFS or Butter-FS or BetterFS or B-Tree-FS... you choose (;
@@Maple-Circuit Thank you.
I'll use all of them.
afaik zfs also can have corruption issues if you aren't using ecc memory and have a double error.
Not really. ZFS uses hierarchal checksumming to prevent such things.
Pretty sure this is a myth that comes from misinterpreting the popular advice that you aren't making full use of ZFS data integrity without ECC. Doesn't mean ZFS is worse compared to OTHER filesystems, in fact it is better.
B Tree File System is still not stable. IEven the engineers who develop it say so, and do NOT convert in place an extra file system to a birds unless you like playing Russian roulette. Data Destroyer.
One just needs to be aware of the limitations before willy billy launching into using birds.
On the other hand, ZFS is rock-stable.
Correction, BTRFS is stable. In-place upgrade is not and can never be stable.
You must be looking at a very old comment to think that BTRFS isn't stable, since it is used in production and is the default in many distros.
What???
Linux-based systems certainly so use Zettabyte File System despite it not "being in the kernel."
The narrator should have corrected his scriptwriter, because that person doesn't understand that ZFS does not need to be "in" a Linux kernel. 😮
Narrator and scriptwriter are the same. And yes, there have been implementations of ZFS on Linux. but you have to admit that if its not in the kernel, there is no widespread use of it!
@@Maple-Circuitit's not in kernel due to cddl licensing issues with gpl... it's heavily used. Wendell from level1techs talks lot about it.
@@Maple-Circuit Ubuntu ships with it... You don't even to compile anything.
Don't have a COW, but not copy on write either of B Tree File System or Zettabyte File System.
😮
They are both redirect on write systems.
look at pinned comment...