As to best practices go RAID 1 or 10 or Single if you don't need raid. If you can duplicate your metadata 3 times (RAID1(0)c3) Do a srub every month or two, doesn't need to be often and after that do a btrfs balance. That's pretty much all. Tips: Use reflink copies whenever possible (cp --reflink always) It will create copy without physically copying the data. Only the new metadata will be created, similar to sym/hard links. It just doesn't come with any of the drawbacks. It's like dedpulication and can be used like that. ;)

@@LampJustin Thank you! I heard about reflinks but never really have an application for them at the moment. Oh and that raid setup 100%!

@@duser yeah it's really useful for dealing with VMs, cloning them with that flag is pretty nice and safes not only time but space as well. Good thing is that latest gnutils set the --reflink auto by default. So whenever you copy stuff it will get reflinked. Nautilus on Gnome also does the same

kzfaq.infoPF77M2V0UYs?feature=share

lol same, I literally searched it yesterday

I can't believe it's not butter

same... I am planning to migrate my ext4 gentoo to btrfs since a while but been lazy to research bout btrfs. but now Jay solved it

Mmm, toast. Now with butter!

I’ll consider doing more

Yeah good recommends! But for me those would be too many subvols to keep track of and snapshot. I just have @ @home and libvirt images of course. I really don't like the naming but that's what you need for Timeshift........ Also yes you really shouldn't use subvolids in fstab or anywhere. Just renaming the subvols to rollback is a must.

The most optimal defaults differ form usecase to usecase. However it would be nice for fedora to step up their btrfs game, as it comes by default, the current one is an extremely vanilla setup and definitely less than ideal.

This! RAID 0 and RAID 1 are perfectly fine and work even better than md-raid. It's just RAID 5/6 that are incomplete (although errors are extremely rare with proper use - similar guarantees as md-raid on Linux kernels prior to 4.4).

If RAID 5/6 had never been released, the BTRFS story would be really simple: “It’s a very reliable, flexible, and full feature modern file system for the desktop, and and anywhere else you don’t need big pools of disks.” As a bit of a ZFS zealot, I have to say BTRFS is really good.

"Something even the mighty zfs can't do for now (changing vdev structure)" Nonsense. ZFS can easily add/remove disks from stripes, and add mirrors to those disks--i.e., do exactly what you described that you did. But parity RAID vdevs can't (currently) be changed; that's been Coming Soon™ for a number of years.

@@danbrown586 are you saying ZFS can take a two disk stripe vdev and convert it to mirror vdev on the fly and back to stripe?

@@LucS0042 Well, there's no such thing as a "two disk stripe vdev"; that would be two single-disk vdevs striped together. But with that caveat, it seems a strange thing to want to do, but yes, ZFS can do it.

ZFS, Btrfs losses data if you use anything but single drive, mirror, or stripe mode.

Anything other than pure RAID 1 or RAID 0 will eat data and will probably never be implemented correctly.

I used BTRFS for @, @home, and @data subvol. I do dual boot Ubuntu with windows. With BTRFS it can share file directly with WinBTRFS. My laptop small SSD can fit much of data with it's compression. Some game like DotA 2 compressed at almost 50% ratio. I install all my program at BTRFS, also set my fav folder like download, document to @data subvol. Data deduplication also work in Windows. That is very much better integration than old school ext4.

​@@Julian-sj5tr compressing Dota 2 doesn't hurt performance? (fps)

@@TheGeoreyexactly my thought

I write too long stuff. TL;DR: Yes. I use it now for few years for hundreds of games spanning over 3.5TB, btrfs just works. I use @games subvolume, mounted at /mnt/games. I use and recommend Steam flatpak, fully sandboxed (all access to my files revoked), gave access to /mnt/games:rw (read write permissions from flatpak), just works. And it can’t mess with my personal files at all. btrfs is the successor of ext4, it basically can do over 99% of what ext4 can do, but much more at same, little worse, or even better performance. Of course they are extremely different fs, but for end user, I can’t say anything other than it just works. When paired with ECC RAM. But if not having ECC RAM, the other fs suffer the same, but they don’t tell you. Btrfs on the other hand knows e.g. when your file integrity is broken. But btrfs trusts the CPU and the RAM, so it will tell you your disk is broken or that cosmic microwave background radiation hit your NAND cell and broke some data on the disk, it won’t tell you data read is correct, but the one in the RAM is faulty, it does not know that, it thinks errors detected are from the disk. It assumes your CPU and RAM do not lie. When using btrfs raid 1 or 10 (with data copy) it periodically checks file integrity automatically, cause it hashes or checksums each file (always, that’s how it detects errors), if it detects mismatch, it will automatically check the other disk and repair broken data automatically, cause it knows if something is broken, and in RAID 1 case has a fully functioning copy. So awesome for system and documents and so on. If you don’t care about games integrity you can just ignore that feature, but it is still a good fs. You can use snapshotting, e.g. when modding a game, when an update broke your game mods, you can then look into snapshot and restore stuff or whatever. Only limitation is your imagination. It is better than ext4, allows resizing, and whole lot more features, comparable to zfs,.. so of course it is a good option. It is also newer than zfs, in my view it is better than zfs, but it depends. E.g. BSD NAS should use zfs. But for desktop, or server, always btrfs. But still, ext4 is good filesystem as well, as well as xfs, they are good choice as well. For games it does not matter that much. I recommend for system and home, two NVMe SSD, e.g. Micron 7400 Pro with power loss protection, using dm-crypt / luks on them, on top of that btrfs (in RAID 1 fully copy mode), and ECC RAM. Then maybe unencrypted additional SSD, e.g. FireCuda 530, btrfs for games. ECC RAM is no bottleneck in gaming. I just ‚downgraded‘ speed, from 64kMiB 3.6GT/s cl16-19-19-19 to 128kMiB 3.2GT/s cl22-22-22 ECC RAM - literally no difference in FPS (I play at 4k). If you have stutter in CSGO, right click, properties, compatibility, choose Steam Linux Runtime, working in Flatpak as well, they made it compatible, sandboxing works with native performance.

LVM is easier to implement then btrfs. It is probably easier to use btrfs, but LVM is easier to implement, and then you just add ordinary file systems on top of LVM. But btrfs is combination of LVM and a modern fs. But it is actually another implementation based on ZFS, which is better then btrfs, as it is older and design by people that actually knows how to run huge servers. That said, btrfs features are not bad, and a bit lighter then ZFS. So all features in btrfs is in ZFS, but not everything in ZFS is implemented in btrfs (like RAID etc).

@@AndersJackson there is RAID in btrfs

LVM and btrfs are not for the same purpose. The first is a system for managing physical or logical volumes and disks but sencond is a file system. We can user btrfs in out LVM logical volumes.

@@squishy-tomato fair, but I just wanted make it clear that RAID1(0) is indeed stable and totally usable. I already have some corruption from time to time, because of a bad controller. BTRFS does it's job great and corrects those flipped bits just fine. And yes I should definitely swap the controller, but cannot right now...

Yes btrfs is not raid

He hinted GUI end use it when he mentioned TimeShift but he did not go into it. I agree with you that the average Linux beginner (myself for example) is not going to want to modify fstab files manually or run all these command lines.

I think Suse has developed a GUI.

Check "man btrfs-convert" for documentation. It can convert an existing ext4 filesystem in-place into btrfs (without losing any data). If you decide that you didn't like btrfs, you can even roll-back to original ext4 (and get back the same contents of ext4, as it was before initial conversion) ... however rollback only works until you have run btrfs-balance for the first time. You should preferably make a backup and boot from USB stick, when doing the conversion.

This video tells about creating subvolume during installation. I don't know if this helps. kzfaq.info/sun/PLwQD7rvZhbK-L6JlQwqOSP3DvMUmvbPvj

You will need ecc-memory for ZFS, or so i read on the internet, because allegedly there is no inherent repair mechanism, unlike in ext4. So a small error on writing can lead to data corruption . I always wonder how that works when you have a power outage... You might get an error too, which might not be correctable by ECC...

@@johnp9890 There is no filesystem in the world, that can protect you from memory errors, for that you always need ECC memory. That is the reason, that for servers they always recommend using ECC memory and because ZFS is mainly used by servers, they often recommend it for ZFS too. The repair mechanism in ext4 or ntfs is inferior to OpenZFS or btrfs. Ext4 (or ntfs) are only able to repair inconsistencies in the disk administration by using their journal. Ext4 or ntfs are incapable to correct internal file errors caused by bitrot or crashes during rewriting the file. If you end up with half the new file and half the old file, there is a fair chance that the application can't read that file anymore. Ext4 or ntfs cannot correct errors in the 10,000 different internal file formats in use, a system crash during rewriting e.g a mp3 file can cause problems during playing that corrupted file. OpenZFS and btrfs are transactional file systems based on Copy on Write, so the file will be either the new version or the old version before the crash. In all cases the internal file format will be correct and you can still play e.g that mp3 file. You did not understand an essential part of the video, so I advice you to watch it again, staring at 4:00 or google for the Copy on Write mechanism.

@@bertnijhof5413 ok. But if you do not have ECC memory installed i read that ZFS might lose a bigger problem if a crash does occur, because allegedly it has less repair mechanisms then ext4. Or so some sources on the internet say....

@@johnp9890 there is nothing in ZFS that makes it inherently dependent on ECC memory. But a computer with ECC memory will be able to protect your data better than one without it, no matter what file system is used. So yes, for absolute maximum data integrity, use ECC memory. But even without ECC memory, ZFS is the safest PC file system that I am aware of. BTRFS would be the only other contender. But I’m a file system enthusiast and not an expert so I could have missed something. I think the “must use ECC memory myth comes from two places within the FreeNAS (now TrueNAS ) forums. That “knowledge” then spread until it became gospel that you had to use ECC memory with ZFS. First, as a file system built for “big iron” and focused on data integrity, it was natural that the systems it first shipped on had ECC memory. When it became open source and moved into the PC space, it appealed to people willing to sacrifice some performance for the extra data integrity it offered. With that focus, the only “proper” way to deploy ZFS was with ECC memory because that gave the greatest possible data integrity. So that was the standard recommend for anyone inquiring about what hardware to use. So slowly “it’s even better with” morphed into “you have use” ECC memory because that is how to make the most of ZFS. Second, in the FreeNAS forums there was a very active contributor who was fairly knowledgeable about hardware selection and various aspects of setting up your ZFS storage for your intended use case. He wrote an essay about how ECC memory was essential because otherwise one memory error could cause cascading failure because it would caused a mismatch with the data and metadata on disk, with one failure leading to another, to another, to another, and so. According to his essay, without ECC memory, your ZFS storage pool was effectively a ticking time bomb, just waiting for the first bit flip in memory to bring the whole house of cards crashing down. The problem is it wasn’t an accurate assessment of how ZFS works and the consequences of a memory error. To the extend that a memory error will affect what is stored on disk, ZFS is either less vulnerable or no more vulnerable than any other file system. The other issue raised by some people against ZFS is that it doesn’t offer the tools to repair a corrupted file system that are present for other file systems. The response from ZFS experts, of which I am not one, is that the types of problems those tools repair don’t appear on a ZFS system because it is designed not to have them. The types of problems that can occur on a ZFS system are so severe that they would be just as unrecoverable as on any other file system. One other myth about ZFS is that you need to have at least one gigabyte of memory for each terabyte of storage. ZFS caches as much of your data as it can, so the more memory that you give it, the greater the likelihood that your data can be retrieved from RAM rather than disk. RAM is much faster than even the fastest SSDs, so yes, more memory is a good thing for ZFS. How much you’ll benefit from more RAM will depend greatly on the workload, type of data your storing, and the layout data sets, disks, and vdevs that make up your storage pool.

@@williamp6800 To support your last paragraphs with a practical example: On my backup server I use FreeBSD 13.1 with OpenZFS. It runs on a Pentium 4 HT (1C2T; 3.0GHz); 1.5GB of DDR (400MHz) and 4 HDDs in total 1.21TB (2x IDE 3.5" and 2x SATA-1 2.5"). Normally it uses around 1GB of memory receiving the backup, but I must be honest OpenZFS bypasses the memory cache (L1ARC) for the backup. However I can also use the system as desktop without problems using e.g Firefox 101 :) The advantage: my investment was $0 and the disadvantage: the backup takes 1 to 2 hours, because it runs at 200Mbps instead of 1 Gbps, due to a ~95% load on one of the CPU threads. That 19 year old CPU is getting somewhat slow for these modern times :) :(

I hope to do exactly that :)

It's working like a charm. Mine already does for about 4 years.

To properly use Timeshift you need to install Fedora with the Rootsubvolume name of @ and the name of home as @home. Otherwise ts doesn't work. This can be done afterwards as well without any problems or recovery media. Mount the btrfs partition with the subvolid of 5 to mnt (mount -o subvolid=5 /dev/sda3 /mnt) Then go into that dir and move root to @ and home to @home. (cd /mnt; mv root @; mv home @home) Your running system won't even notice, check it out with mount (mount | grep " / ")! Now you'll need to change fstab to reflect the change as well. In particular just change the names from root and home to @ and @home. At last change your current active grub boot entry from subvol=root to subvol=@. Reboot and e voila, you did it. That's also how you would restore a snapshot on a running system, just without changing fstab and grub.

@@LampJustin what exactly doesn't work with "sane" names for my subvolumes? I have set it up with the default names as fedora uses them and Timeshift seemed to work. Or well, it didn't work well because I needed 4 subvolumes to be handled, therefore I switched to snapper

@@matthiasbendewald1803 I am not sure what you're trying to say, but for whatever reason TimeShift only supports doing snapshots for the @ and @home subvolume. Fedora instead names to root volume root (-> @) and the home volume home (-> @home). That's why I renamed them like stated before. I Infact also have more subvols but as expected TimeShift will completely disregard them.

@@LampJustin okay then I must have mixed things up. Maybe I had used that rsync option in Timeshift? Whatever, thanks for the answer!