What are the advantages of Btrfs for end users?
From wiki:
Extent based file storage 2^64 byte == 16 EiB maximum file size Space-efficient packing of small files Space-efficient indexed directories Dynamic inode allocation Writable snapshots, read-only snapshots Subvolumes (separate internal filesystem roots) Checksums on data and metadata Compression (gzip and LZO) Integrated multiple device support RAID-0, RAID-1 and RAID-10 implementations Efficient incremental backup Background scrub process for finding and fixing errors on files with redundant copies Online filesystem defragmentation
Explanation for desktop users:
- Space-efficient packing of small files: Important for desktops with tens of thousands of files (maildirs, repos with code, etc).
- Dynamic inode allocation: Avoid the limits of Ext2/3/4 in numbers of inodes. Btrfs inode limits is in a whole different league (whereas ext4's inodes are allocated at filesystem creation time and cannot be resized after creation, typically at 1-2 million, with a hard limit of 4 billion, btrfs's inodes are dynamically allocated as needed, and the hard limit is 2^64, around 18.4 quintillion, which is around 4.6 billion times the hard limit of ext4).
- Read-only snapshots: fast backups.
- Checksums on data and metadata: essential for data integrity. Ext4 only has metadata integrity.
- Compression: LZO compression is very fast.
- Background scrub process to find and to fix errors on files with redundant copies: data integrity.
- Online filesystem defragmentation: autodefrag in 3.0 will defrag some types of files like databases (e.g. firefox profiles or akonadi storage).
I recommend you the kernel 3.0. Also btrfs is a good FS for SSD.
For the benefits: I believe it will be mainly the backup and mirroring features.
But why would you be so hasty as to think of btrfs as a filesystem ready to replace any of your current ones? Both the wiki you refer to :
(...) it is currently possible to corrupt a filesystem irrecoverably if your
machine crashes or loses power on disks that don't handle flush requests
correctly. This will be fixed when the fsck tool is ready.
and the 3.0 kernel documentation
Btrfs filesystem (EXPERIMENTAL) Unstable disk format
(...)
Btrfs is highly experimental, and THE DISK FORMAT IS NOT FINALIZED.
You should say N here unless you are interested in testing Btrfs
with non-critical data.
clearly discourage you from using btrfs for any other purpose than testing.
But when it comes to form, I believe for the end-user will only have value for private data like things in one's home directory. There will be no need for the safety net of moving things to trash - actually there will be a need of redefining the "trash" on desktop environments. Rest of the features will probably just end up (to the user) as feeling faster (if at all), but more quickly eating up the disk space.
BTRFS has matured considerably over the years (since this question was asked). It's now pretty stable for most simple use cases, even for different RAID levels (e.g., RAID-1 - stable and easy to set up). Given the fact that BTRFS stores checksums, it's able to reliably detect corruption (unlike classic RAID systems where only parity is available).
Current versions are even able to fix typical errors in a BTRFS RAID-5 filesystem (for example by replacing a failed drive) (although raid56 still needs improvement, see update below).
If a repair/replace operation crashes, first update the kernel (which probably fixes this issue) - and if necessary, BTRFS has some recovery features. Even in the worst case (like multiple drive failures), you'll often be able to copy the files that are still ok and you'll know which files are damaged. So ignoring all those other features (like snapshotting, CoW copies, subvolumes), BTRFS could be used if detecting data/file corruption is a main priority.
Update: In June 2016, it was discovered that the RAID-5/6 implementation in BTRFS is flawed. BTRFS in general is stable - but the raid56 implementation is very new, has been considered experimental anyway and should now only be used for testing until it's been fixed. If you're using RAID-5/6, you might want to convert to RAID-1. It still offers advantages for end users like checksumming (other filesystems may not know about corrupted files at all) and protection if a drive fails.
Reference: BTRFS sometimes calculates wrong parity