Understanding BTRFS Space Allocation
In traditional filesystems like ext4 or XFS, a partition is allocated a fixed amount of space. If you create two mount points on separate partitions, they cannot share unused space from each other. BTRFS changes this model entirely. When you format a drive with BTRFS, the entire device becomes a single filesystem instance. Any directory within that filesystem shares the same underlying storage pool.
This means that if you have a 1TiB BTRFS partition and mount it at /data and another directory at /home, both paths access the same physical blocks. Writing a large file to /data reduces the free space available for /home. There are no separate quotas unless explicitly configured using subvolumes. This behavior simplifies storage management because you do not need to calculate how much space each application needs; the system handles dynamic allocation automatically.
Mounting the Filesystem
To utilize this feature, you must ensure that all desired mount points belong to the same BTRFS instance. You typically achieve this by mounting the root of the BTRFS filesystem to a base directory, such as /mnt/storage, and then creating subdirectories within it. Alternatively, you can use bind mounts, though native subvolumes are generally preferred for better integration with BTRFS features like snapshots and compression.
For example, if your device is /dev/sdb1, you would mount it as follows:
mount /dev/sdb1 /mnt/storageOnce mounted, you can create subdirectories that act as distinct logical spaces while sharing the same pool:
mkdir /mnt/storage/videos
mkdir /mnt/storage/documentsBoth /mnt/storage/videos and /mnt/storage/documents will draw from the same 1TiB pool. If /mnt/storage/videos uses 500GiB, only 500GiB remains for /mnt/storage/documents.
Using Subvolumes for Logical Separation
While simple subdirectories share space implicitly, BTRFS subvolumes offer a more robust way to manage these shared spaces. Subvolumes are lightweight copies of the root directory that can be mounted independently. They allow you to apply different mount options, such as compression or noatime, to specific sections of your data without affecting the rest of the filesystem.
To create a subvolume, first ensure the filesystem is mounted read-write:
btrfs subvolume create /mnt/storage/subvol_a
btrfs subvolume create /mnt/storage/subvol_bYou can then mount these subvolumes to different locations in your system tree:
mount -o subvol=subvol_a /dev/sdb1 /home/user/projects
mount -o subvol=subvol_b /home/user/mediaEven though these are mounted at different paths, they still share the underlying storage capacity of /dev/sdb1. This approach is particularly useful when you want to isolate applications or users while maintaining efficient storage utilization.
Managing Disk Usage
Monitoring space usage in a shared BTRFS environment requires understanding that usage is reported per-subvolume but deducted from the global pool. The command btrfs filesystem df provides detailed information about data, metadata, and system block groups. It shows how much space is used and reserved across the entire device.
If you notice unexpected space consumption, check for duplicate extents caused by copy-on-write operations. BTRFS may store multiple copies of identical files if hard links are created incorrectly. Use btrfs filesystem du to see the actual disk usage versus apparent size. This helps identify if multiple mount points are inadvertently duplicating data rather than sharing it efficiently.
Common Pitfalls and Best Practices
One common mistake is treating BTRFS subvolumes as independent partitions. Users often assume that creating a new subvolume allocates new space, which is false. All subvolumes compete for the same resources. Therefore, it is crucial to monitor overall filesystem health rather than individual subvolume sizes alone.
Another consideration is the balance operation. Over time, fragmentation can occur, especially with frequent writes across multiple mount points. Running btrfs balance start periodically helps redistribute data evenly across disks, ensuring optimal performance. For systems with multiple physical drives, consider using RAID profiles to enhance redundancy alongside space sharing.
Refer to our guide on BTRFS Partition Completely Full: How to Make it Workable Again if you encounter issues where the shared space appears full despite low usage in individual directories. This often indicates metadata exhaustion or snapshot retention policies consuming hidden space.
Frequently Asked Questions
Can I set strict quotas for each mount point?
Yes, you can enforce quotas using btrfs qgroup commands to limit the maximum space a subvolume can consume. However, this requires careful planning as exceeding the quota will cause write errors. It is generally recommended to rely on natural usage patterns unless specific isolation is required.
Does mounting multiple times reduce performance?
No, mounting the same filesystem to multiple directories does not inherently degrade performance. The kernel handles the lookup efficiently. Performance depends more on the underlying hardware speed and the efficiency of your I/O scheduler rather than the number of mount points.
What happens if one mount point fills up completely?
If one mount point consumes all available space, all other mount points sharing that BTRFS partition will also become full. Since they share the same pool, there is no remaining space for any other directory. Regular monitoring and automated cleanup scripts are essential to prevent total storage exhaustion.
How do I verify that two directories share the same space?
You can verify this by checking the output of df -h for both mount points. They should report the same total size and available space. Additionally, using stat -f on both directories will show identical filesystem IDs, confirming they belong to the same BTRFS instance.
Can I mix BTRFS with other filesystem types on the same drive?
No, a single block device formatted as BTRFS cannot contain other filesystem types like ext4 or NTFS simultaneously. Each partition or whole disk must be dedicated to one filesystem type. To combine different filesystems, you would need separate partitions or devices.