Re: enquiry about autodefrag option

[Martin Steigerwald <Martin@lichtvoll.de>]

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