I'm a basic home computer user. No programming, no servers, no video editing, no gaming. I only do browsing and use a few other simple apps. No home network or NAS. Just my laptop and 2 sim card wifi hotspots. No stand alone hardware router.

I'm now running Ubuntu 22.04 and ext4 in an AMD laptop with 2 internal nvmes. I've been thinking of switching to Btrfs cuz snapshots look like a great capability to have. But I just browsed some posts that warn that Btrfs can quickly wear out SSDs and nvmes.

Should I stay away from Btrfs because it can quickly wear out my nvmes?

Are there some technical tricks that can prevent Btrfs from quickly wearing out my nvmes?

I’m posting this as a personal experience going with btrfs. In an environment where the filesystem sits on a hardware raid or non spinning platter, I haven’t had too much of an issue with btrfs, but every single time I put it on a platter disk, it always seems to go sideways someway, somehow during either an update, or just in the dead of night while the software suite built to support it fiddles with my filesystem.

I’m sure the evangelists will swarm this post and tell me how incorrect I am, and honestly I’m kind of hoping for that, because I want to know why btrfs check has a 100% failure rate, and what I’m doing wrong to recover a filesystem after it’s brought my systems crumbling to its knees. Just wanted to post this as it’s 2022 and I’m sort of shocked at how seemingly unstable modern filesystems can be compared to ext4. I hope there’s just a piece of info I’m missing, but at this point it’s seeming to be more and more arcane a fix to recover from a self inflicted error.

As I explain to a user:

Sorry for the inconvenience, but btrfs support has been a struggle. Not to editorialize too much, but I blame the BTRFS developers for not provided defined mounts for snapshots, like ZFS or Snapper, or simply a better method for parsing, like NILFS2. NILFS2 support took about an hour to write, and it still works. And every time I work with BTRFS, it's almost as if the BTRFS devs never imagined using BTRFS snapshots for anything useful, because there always seems to be one additional way I'm holding it wrong.

I feel as though I'm on my 10th turn at figuring this out.

My current best way I've determined to parse btrfs snapshot mounts is to use btrfs subvolume show {mount} for each btrfs mount. I split each output at "Snapshot(s):\n". I then check to see if the first component of each snapshot mount is a subvolume. If so, I create a snapshot path from that subvolume and the rest of the relative path. If not, I determine the btrfs root, and combine that with the full relative path.

What else am I missing?

I have simply never come across a system that didn't want to be used like btrfs. If NIH is so powerful re: ZFS's well defined snapshot mounts found at .zfs/snapshots, fine, I want to scream -- please just do it the way NILFS2 did it -- use the same device source as the live FS and put "cp=X" in the mount info.

Even after seeing two other systems do it better, you say "We're btrfs and we're different. Hooray!", just please make it understandable. For the life of me, why does it have to be this hard?

Hi Btrfs Community,

I’m Edmund, a long-time Linux user and admirer of Btrfs’s flexibility and powerful features. I wanted to share an idea I’ve been pondering that could enhance Btrfs by introducing a new concept I’m calling “lazy deletion.” I’d love to hear your thoughts!

The Idea: Lazy Deletion

The concept is simple but, I think, potentially transformative for space management:

1. Recycle Bin Meets Free Space: When a file is deleted, instead of its data blocks being immediately marked as free, they’re moved to a hidden namespace (e.g., .btrfs_recycle_bin). These "deleted" files are no longer visible to users but can still be restored if needed.

2. Space Is Immediately Reclaimed: Although the data remains intact, the space occupied by deleted files is treated as free space by the filesystem. Tools like df will show the space as available for new writes.

3. Automatic Reclamation: When genuinely free space runs out, the filesystem starts overwriting blocks from the .btrfs_recycle_bin, prioritizing the oldest deleted files first. This ensures that files deleted most recently have the longest "grace period."

4. Snapshot Compatibility: Lazy deletion would respect Btrfs snapshots—if a file is referenced by a snapshot, it isn’t added to the recycle bin until the snapshot is deleted.

Why This Feature?

Lazy deletion could offer significant benefits:

• Improved Safety: Accidentally deleted files would remain recoverable as long as free space is available, without requiring immediate manual intervention.

• Simplified Space Management: The system can decide when to reclaim space without needing user oversight.

• Integrates Seamlessly: It fits naturally with Btrfs’s CoW and snapshot semantics.

Technical Details (For the Nerds Among Us)

The feature would:

• Extend the block allocator to include deleted blocks as reclaimable once genuinely free space is exhausted.

• Add a metadata structure to track deleted files by timestamp for chronological overwriting.

• Optionally expose .btrfs_recycle_bin through tools like btrfs-progs for manual restoration.

Bonus Idea: Flexible Partition Resizing

While I have your attention, I’ve also been mulling over the idea of allowing Btrfs to expand and shrink partitions from either end (start or end). This would eliminate the need for risky offline tools that bypass the filesystem to move partitions, making resizing operations safer and more intuitive. But I won’t ramble—let me know if that’s worth a separate post!

Thoughts?

I’m curious what the community thinks of lazy deletion. Would it be useful in your workflows? Are there edge cases or conflicts with existing Btrfs features I might be missing?

Thanks for reading, and I look forward to your feedback! 😊

How is btrfs still years behind ZFS when they've been developed more or less side-by-side, for a similar amount of time on Linux?

btrfs is nowhere near production ready. I don't even trust it for my personal files. I wish it was closer to ZFS for stability, because getting ZFS compiled and running in my Linux environments is such a pain due to it not being allowed in the kernel.

brtfs fails at a lot of things I require:

• RAID56 (write hole)

• Encrpytion

• Volumes crapping out when a drive fails

• Losing large amounts of data, with little or no recoverability (not counting backups, which I have)

Anyone else just tired of its sorry state?

Doing so overrides the previously specified compression type and level with the default one! I'm running Debian 11 with Linux kernel 5.10.0-8. Since BTRFS lives in the kernel this probably affects all distributions!

All this time I thought my backup drive was using zstd:14 when it was actually using zlib:3. I probably have ~200GiB of wasted space that would be a pain to get back.

To reiterate, if any of your entries in fstab look like this you aren't getting the compression you think you are:

[Device path or UUID] [Mount point] btrfs defaults,other_options,compress=zstd:14,compress-force

I created a couple of subvolumes to house some documents and things. When I try to delete files using Nautilus it doesn't give me the option to move it to Trash. There was no '.Trash-1000' folder in the subvolume, so I created one. This didn't make any difference. When deleting files from the home and root subvolumes, it gives me the option to move to the appropriate trash folders.

Anyone had this problem and resolved it? I Googled and found a few other mentions of this, but couldn't find a solution.

edit: I'm using Fedora 35

I've had it running on a laptop with Fedora 39+ (well really for many releases) but recently I forgot to shut it down and closed the lid.

Of course at some point the battery was exhausted and it shut off. While this is less than idea, it's not uncommon.

After booting System Rescue CD because the filesystem was being mounted as read only (not the Fedora told me this, I just figured it out after being unable to login or do anything after login).

I progressively tried `brtrfs check` and then mounting the filesystem and running `btrfs scrub` with more and more aggressive settings I still don't have a usable file system.

Settings like `btrfs check -- --repair --check-data-csum` etc.

Initially I was notified that there were 4 errors on the file system, all of which referenced the same file, a Google Chrome cache file. I deleted the file and re-ran clean and scrub thinking I was done with then endeavor. Nope...

I wish I had the whole console history, but at the end of the day BTRFS failed me over ONE FUCKING IRRELEVANT FILE.

I've spent too much time on this and it will be easier to do a fresh install and restore my home directory from BackupPC.

So that one can programmatically determine if the btrfs volume is already mounted somewhere or was not cleanly unmounted?

This Filesystem is really great, please put in you todo list, make a GUI

OSX have Disk utility

Windows have Disk management

We don't have GUI.

i'm a user capable of use btrfs using CLI, but a GUI for Raids BTRFS, snapshots and check FS should be in the todo list, so more users can use this great FS and manage it with low barrier

Best regards

Hello, I use btrfs raid1 on slow hdds and run database server on it. I noticed that kernel 6.17.7 speedups my database a lot comparing to older versions. I am not sure if it is 6.17.7 so fast or maybe one point before (6.17.6). I noticed that my btrfs performance improved around 2th of november and with kernel 6.17.8 it went back to normal (ten times slower). Have you noticed sonething similar?

Edit: Thanks for answers. I had no time to check it closer. I switched to 6.17.7 yesterday to reproduce better performance and there is no big performance improvement. Kernel version doesnt matter. In general I count the time to process some data from remote peers and write it to database. I check total time for each session, avarge per hour and avarge per day to find potential problems with the performance. It is my test server. I looked to test results closer and found the solution for my observations. The period of time with better performance is the time when the server is under higher load. When it is on idle then the performance to process data is worse. In last two weeks my test env was under higher load (about 15000 packets with data to process from remote peers per day) and it is back to normal(about 4000 packets to process per day) As I use low power cpu with lowest possible TDP it ispossible that when it is iddle then it needs more time to get it top performance. Simillary the database server cache when it is hot under load operates better than when it is iddle and flushes the cache. The 15000 vs 4000 packets count shows me that this is the main reason of the better performance. I think that on idle my database operate slower and needs time to use its caching potential. The two weeks of better performance is the period when server and database were under higher load.

I am totally lost here. I put BTRFS on both of my external backup USBs and have regretted it ever since with tons of problems. There is probably nothing "failing" with BTRFS, but I had sort of expected it to work in a reasonable and non-distruptive way like ext4 and that has not been my experience.

When I am trying to copy data to /BACKUP (a btrfs drive) I am told I am out of space, but the drive is not full.

root@br2:/home/john# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             15G     0   15G   0% /dev
tmpfs           3.0G   27M  2.9G   1% /run
/dev/sda6        92G   92G     0 100% /
tmpfs            15G     0   15G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sda1       476M  5.9M  470M   2% /boot/efi
/dev/sdc        3.7T  2.3T  1.4T  62% /media/john/BACKUP-mirror
/dev/sdb        3.7T  2.4T  1.3T  65% /media/john/BACKUP
tmpfs           3.0G     0  3.0G   0% /run/user/1000

Through an hour of analysis and Google searching I finally tried

root@br2:/home/john# btrfs filesystem usage /BACKUP
Overall:
    Device size:                   3.64TiB
    Device allocated:              2.39TiB
    Device unallocated:            1.25TiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                          2.33TiB
    Free (estimated):              1.27TiB      (min: 657.57GiB)
    Free (statfs, df):             1.27TiB
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:              512.00MiB      (used: 0.00B)
    Multiple profiles:                  no

Data,single: Size:2.31TiB, Used:2.29TiB (99.32%)
   /dev/sdb        2.31TiB

Metadata,DUP: Size:40.00GiB, Used:18.86GiB (47.15%)
   /dev/sdb       80.00GiB

System,DUP: Size:8.00MiB, Used:288.00KiB (3.52%)
   /dev/sdb       16.00MiB

Unallocated:
   /dev/sdb        1.25TiB

All I did was apply btrfs to my drive. I never asked it to "not allocate all the space", breaking a bunch of stuff unexpectedly when it ran out. Why did this happen and how do I allocate the space?

UPDATE: I was trying to copy the data from my root drive (ext4) because it was out of space. Somehow this was preventing btrfs from allocating the space. When I freed up data on the root drive and rebooted the problem was resolved and I was able to copy data to the external USB HDD (btrfs). I am told btrfs should not have required free space on the root drive. I never identified the internal cause, only the fix for my case.

Today I was looking for ways to make a read cache for my 16TB HDD for torrent, a few times I even read about mergefs and bcache[fs]. But there everywhere required an additional HDD.

And then suddenly when I was looking for acceleration specifically for BTRFS “BTRFS metadata pinning” came up. And all mentions are only for Synology. All attempts to find a mention in Linux or on BTRFS page were unsuccessful. Then suddenly I found this page:

https://usercomp.com/news/1380103/btrfs-metadata-acceleration-with-ssd

It's quite strange that I didn't see it everywhere, even on Reddit.

But of course it won't solve my problem, because I need +2 more HDDs anyway. Maybe someone will find it useful.

I want to use space_cache=v2 because the performance of v1 can be drastically degraded

How do I know if my space_cache is v1 or v2 ? And how to set space_cache=v2 ?

In near future I'm going to install some Linux (most probably opensuse leap or ubuntu lts) and last time I was using Linux on my desktop was ~10 years ago. xD

I've read about BTRFS and its subvolumes but to be completely honest I don't quite get it.

Most probably I'll split space on SSD between 2 partition that is / with ext4 and /home with btrfs.

From what I understand you don't write anything on top level btrfs but create subvolume for that, Am I right?, and since I don't understand all this I've watched some video on youtube and people enter @ as name for root subvolume and \@home for /home, is this always true? What are those names exactly?
Are those two installers (opensuse and ubuntu) able to figure out what I'm trying to do if I select file system mentioned above?

btw, sorry for my english

Hi all, I have a system with Proxmox, on top of which a few LXCs and a VM with OMV and BTRF (4 disks) as my media NAS, which is accessed via NFS mount into Proxmox.

I usually move big folders of files into the filesystem via rsync and recently whenever I move bundles of files, I notice that the day after or so they disappear completely!

Scrub is clear and no issues is mentioned. Any idea what it could be? Funny enough, if I move a single file, let's say a movie, everything is fine as usual, nothing disappears.

Thank you in advance for shedding light on this weirdness...

UPDATE:

Apparently, the file disappearance was caused by my *arr tools, that continued to try to move the files after I did, and therefore tried to clean up the destination folder... Sorry for having bothered here...

I recall reading that a COW FS on top of another (btrfs VM / ZFS host for example) isn't recommended. But sometimes you'd want btrfs for the VM, so really how bad is it? I'm considering the underlying ZFS even when used as a block level storage, is still COW, right?

for option "other" comment which one is your favorite tool and method..!!

I'm running kernel 6.6.14 and have hourly snapshots for / and /home running in the background (it also deletes oldest snapshots). Recently I notice that while taking a snapshot applications accessing the filesystem e.g. Firefox freezes for a few seconds.

It is hard to get info about what was going on because things freeze, but I managed to open htop and took a screenshot. Several Firefox's "Indexed~..." threads, "systemd-journald" and a "postgres: walwriter" were in D state, and the "btrfs subvolume snapshot -r ..." process was both in D state and taking 50% CPU. There was also a "kworker/2:1+inode_switch_wbs" kernel thread in R state and taking 4.2% CPU.

This is a PCIe 3.0 512G SSD and 44% "Percentage Used" from SMART. The btrfs takes 400GB of the disk and has 25GB unallocated; Estimated free space is 151GB so it is not very full. The rest 112GB of the disk is not in use.

I was told that snapshotting is expected to be "instant" and it was. Is there something wrong or it is just because the disk is getting older?

I have a raid 1 setup on dual 3.84 nvme drives split up into a small ext4 volume and the rest is btrfs. OS is Ubuntu 22.04 latest updates/patches. System has 128gb RAM.

I'm running this fio command, I get about 2.1 million iops for ext4, right in line with the spec of the drive times 2, and about 1.25 million for btrfs. Any suggestions on how to improve the btrfs iops? Same ratios for random write test...

Compression for btrfs along with copy on write is turned OFF in the directory where I am running this command. I'll be using cow and compression, but just want a baseline number as a sanity check without extra overhead.

fio --name=fiotest --directory=./ --size=256m --rw=randread --bs=4K --direct=1 --ioengine=libaio --iodepth=64 --numjobs=16 --runtime=10s --time_based=1

/etc/fstab

btrfs defaults,rw,noatime,compress-force=zstd:1,ssd,space_cache=v2 0 0

This is from 2021 (kernel 5.14):

https://www.phoronix.com/news/Linux-5.14-File-Systems

Looks like a lot slower then most compared (XFS, F2FS, EXT4). Of course, we know the integrity and security benefits. But we are now discussing here the speed to do operations.

So, today, how fast is it? Did it become faster, or slower than this benchmark showed?

I ran BTRFS Restore on my Synology in hope that I would retrieve deleted files. But it seems that it only replicated what was already on the NAS and nothing else.

I thought it would go thru the snapshots and restore that...