Am Mittwoch, 19. September 2012 schrieb Liu Bo: > On 09/19/2012 07:28 PM, ching wrote: […] > > On 09/17/2012 07:15 PM, ching wrote: > >> I am testing btrfs for long-term storage and backup, and i would > >> like to know more about "autodefrag" option: > >> > >> 1. Will "autodefrag" option benefit ssd? > >> > >> My understanding is: > >> > >> autodrag -> number of extent decrease -> metadata decrease -> > >>a > >> > >> "healthier" filesystem in the long run > >> > >> (P.S. I am aware that autodefrag will introduce extra write I/O) > > Yes, your understanding is right, random write workloads will benefit > from it.
What about the extra I/O? And the greatly reduced seek times on SSDs? Upto now I kept away from defragmenting on SSD. I wonder about a good way to decide whether autodefrag makes things better or worse for a specific workload. What are the criteria on rotating media and what are they on SSD? [… informational part about a BTRFS on SSD that should have an age of at least 8 months with almost daily upgrades …] I only have / running on SSD, but this since quite some time. And it does not seem to have gotten much worse – however this is only subjective feeling of performance. Except for fstrim times. fstrim take way more time than in the beginning¹. So there seems to be free space fragmentation. Which makes sense for a root filesystem on a Debian Sid machine with lots of upgrade activity and way over 50% usage. merkaba:~> df -hT / Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf /dev/dm-0 btrfs 19G 13G 3,6G 79% / merkaba:~> btrfs fi sh failed to read /dev/sr0 Label: 'debian' uuid: […] Total devices 1 FS bytes used 12.25GB devid 1 size 18.62GB used 18.62GB path /dev/dm-0 merkaba:~> btrfs fi df / Data: total=15.10GB, used=11.58GB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.75GB, used=688.96MB Metadata: total=8.00MB, used=0.00 I think I get rid of that duplicate metadata once I redo the fs with 8 or 16 KiB metadata blocks. I thought about rebalancing it, but last time boot time doubled after a complete rebalance. The effect of a rebalance of just the metadata tree to one instead of two might be different tough. Intel SSD 320 300GB on Kernel 3.6-rc5. [1] It has been a second or two in the beginning I think. Then it grew over time. merkaba:~> time fstrim -v / /: 5877809152 bytes were trimmed fstrim -v / 0,00s user 5,74s system 14% cpu 39,920 total merkaba:~> time fstrim -v / /: 5875712000 bytes were trimmed fstrim -v / 0,00s user 5,55s system 14% cpu 39,095 total merkaba:~> time fstrim -v / /: 5875712000 bytes were trimmed fstrim -v / 0,00s user 5,62s system 14% cpu 38,538 total -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html