I know about cow filesystem, it makes a new version of the modified file and stores it on another location on the hdd, but the old version of files that are no longer in use, how does btrfs manage those old versions of files that would’ve been deleted on a journaling fs(how and when does btrfs free the space on the drive)? I was reading the arch wiki and other btrfs sources but im still in the dark about this question…
CoW filesystems keep track of changes in the files. So there isn’t an old version and a new version exactly…more that there is just the one version, and then Btrfs “remembers” that you made such-and-such changes to it.
In certain cases, a file will be re-written. But in many cases that is not needed; a CoW filesystem just keeps tracking the changes as you go and puts things together on the fly.
This has been a very over-simplified explanation but I hope it helps think about it in a new way at least.
seems logical, but then the hdd will just get filled, and somewhere along the way it will delete some files. how would that look when you look at the hdd, is it filled or is it showing empty or what( and on what percentages it decides to delete/remove something, cow is confusing)…
Any disk will eventually be filled if you keep putting stuff on it, no matter what filesystem is in use.
With Btrfs, you should periodically defragment the filesystem. This will “redo” the files so they are in a less scattered state, and Btrfs does not have to track so many extents for each file. This is especially true for a HDD, since reading a fragmented file is much slower on spinning rust.
This question is somewhat unclear, but it is true that getting a read on how much space is actually in use on Btrfs is somewhat tricky. It is best to use Btrfs-specific tools for reporting usage information because “regular” tools can be inaccurate. From the ArchWiki Btrfs page:
Displaying used/free space
General linux userspace tools such as df(1) will inaccurately report free space on a Btrfs partition. It is recommended to use
btrfs filesystem usageto query Btrfs partitions. For example, for a full breakdown of device allocation and usage stats:
# btrfs filesystem usage /
btrfs filesystem usagecommand does not currently work correctly with
btrfs filesystem dfallows a quick check on usage of allocated space without the requirement to run as root:
$ btrfs filesystem df /
See  for more information.
The same limitations apply to tools which analyze space usage for some subset of the filesystem, such as du(1) or ncdu(1), as they do not take into account reflinks, snapshots and compression. Instead, see btduAUR and compsize for btrfs-aware alternatives.
Or, again, the extremely useful Btrfs Assistant application is a great way to get an idea of how much space is in use.
Generally CoW just means that a new chunk is written elsewhere instead of overwriting the old chunk. As long as the old chunk is needed (e.g. it is part of a snapshot) that chunk is still in use and will require space. If the old chunk is no longer needed it is marked as free to use after the new chunk is written (similar to other file systems).
that i kinda understand, i read that somewhere before… but btrfs is weird, i made the other thread, where i made format with ntfs in win just because, then went into linux, deleted it and formated with btrfs(new and unused hdd) and when it formated the disk with btrfs i had 2gb used space, and i kinda want to know why is that, probably btrfs shifted something else there from other hdds or it reserved some space for something…
Btrfs is going to take a some space for internal organization (metadata to keep track of all those chunks). That can be 2 GB if it is a bigger drive. So depending on which tool you used it’s possible that tool shows a 2 GB difference in available space on a newly formatted drive between btrfs and other file systems.
the drive is 18tb wd ultrastar. i used kde partition manager… yeah it is probably something like that maybe…
For science I just formatted a 500 GB drive. The KDE Partition Manager shows me 79 MB used with ntfs and 2 GB with btrfs.
From the btrfs wiki: A typical size of metadata block group is 256MiB (filesystem smaller than 50GiB) and 1GiB (larger than 50GiB), for data it’s 1GiB. The system block group size is a few megabytes.  So 2 GB is well in the ballpark for these bigger drives.