I'm running a Linux system (based on Gentoo) with a BTRFS file system installed on an SSD (Toshiba Q300 with 480GB net).
My /etc/fstab
looks like:
UUID=14cb9b65-... swap swap defaults,noatime, 0 0
UUID=cd7d93b3-... / btrfs defaults,cache,compress=lzo,subvol=@ 0 1
UUID=cd7d93b3-... /home btrfs defaults,noatime,space_cache,compress=lzo,subvol=@home 0 2
UUID=cd7d93b3-... /Data btrfs defaults,noatime,space_cache,compress=lzo,subvol=@Data 0 2
UUID=cd7d93b3-... /mnt/rootfs btrfs defaults,noatime,space_cache,compress=lzo 0 0
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 tmpfs /proc proc defaults 0 0
tmpfs /var/log tmpfs defaults,noatime,rw,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,rw,mode=1777 0 0
tmpfs /var/run tmpfs defaults,noatime 0 0
tmpfs /var/spool tmpfs defaults,noatime 0 0
tmpfs /var/lock tmpfs defaults,noatime 0 0
tmpfs /var/cache tmpfs defaults,noatime 0 0
tmpfs /run tmpfs defaults,noatime 0 0
sysfs /sys sysfs defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
devtmpfs /dev devtmpfs gid=5,mode=620 0 0
Before, I had an Intel SSD with 240GB net with XFS file system.
When I executed the fstrim -v /
for that XFS system, which I did daily, I rather received messages like:
8 Gigabytes trimmed.
Now, on top level of the 480GByte Toshiba SSD, I have several Subvolumes like:
# btrfs subvolume list /mnt/rootfs
ID 264 gen 273 top level 5 path @_original_install
ID 265 gen 152 top level 5 path @home_install_ok
ID 266 gen 270 top level 5 path @_snapshot_install_ok
ID 267 gen 28504 top level 5 path @
ID 275 gen 28504 top level 5 path @home
ID 276 gen 26900 top level 5 path @Data
ID 607 gen 245 top level 5 path @_snapshot_home_20160330
ID 628 gen 3837 top level 5 path @_root_snapshot_20160402
and when I start the fstrim
command, I receive this result:
***************************************** # fstrim -v /mnt/rootfs/@ 177,3 GiB (190331097088 Bytes) getrimmt *****************************************
Why is the amount of trimmed space 177 GiB, instead of maybe 8 or 10 like on my old XFS formatted 240 GB SSD?
After trimming my 480GB Toshiba SSD again just after first trim, the result is almost the same, 172 GiB were trimmed now.
So: Does fstrim
not work for BTRFS?
And, do you know a (very) good tutorial / website or similar, which explains BTRFS, including how subvolume work, what about Meta data?
The more infos on latest btrfs-progs (I use version 4.4.1) the better. If in German, it would be great, too…
And, is it harmful to the SSD, when trimming, or when trimming often?
Best Answer
From the BTRFS Wiki FAQs:
I see you're not mounting with
-o ssd
. Perhaps yourbtrfs-progs
isn't detecting it as a SSD. (It checks if/sys/block/sdX/queue/rotational
is 0.)"
-o ssd
will not enable TRIM/discard" probably because excessive overwrites wear out SSD drives faster.The
fstrim
manpage says:Also, BTRFS's CoW (copy-on-write) is advantageous for SSDs, minimizing unnecessary overwrites, so TRIM isn't really that necessary with BTRFS. Non-CoW filesystems on SSDs need TRIM turned on.
Perhaps it's related to
ssd_spread
not being on, whence you'd have larger, less-fragmented free space:Since your Toshiba Q300 is a lower-end SSD, you should turn on the
ssd_spread
mount option.It does. The BTRFS mount options page says "you can run
fstrim
command periodically."This is the best BTRFS resource: https://btrfs.wiki.kernel.org/
The btrfs-subvolume manpage is good. So is the Subvolumes section of the Sysadmin guide.
btrfsQuota.py
is a neat script for understanding snapshot/subvolume and metadata sizes.The latest is version 4.5.3.
I highly recommend the
btrbk
Perl script for leveraging BTRFS to do automated backups and snapshoting. It really demonstrates the power of BTRFS. The author, Axel Burri, is from Zurich, Switzerland, and, based upon his having a German first name, he likely knows German, too; perhaps he could point you to some German BTRFS resources.Also, doing a search on WorldCat, this book mentions BTRFS, but it's somewhat outdated (2011):