Re: Options for SSD - autodefrag etc?

[Martin Steigerwald <Martin@lichtvoll.de>]

Hi Duncan,

Am Freitag, 24. Januar 2014, 06:54:31 schrieb Duncan:
> Anyway, yes, I turned autodefrag on for my SSDs, here, but there are 
> arguments to be made in either direction, so I can understand people 
> choosing not to do that.

Do you have numbers to back up that this gives any advantage?

I have it disabled and yet I have things like:

Oh, this is insane. This filefrags runs for over a minute already. And hogging 
on one core eating almost 100% of its processing power.

merkaba:/home/martin/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend> 
/usr/bin/time -v filefrag soprano-virtuoso.db


Wow, this still didn´t complete yet – even after 5 minutes.

Well I have some files with several ten thousands extent. But first, this is 
mounted with compress=lzo, so 128k is the largest extent size as far as I 
know, and second: I did manual btrfs filesystem defragment on files like those 
and and never ever perceived any noticable difference in performance.

Thus I just gave up on trying to defragment stuff on the SSD.


Well, now that command completed:

soprano-virtuoso.db: 93807 extents found
        Command being timed: "filefrag soprano-virtuoso.db"
        User time (seconds): 0.00
        System time (seconds): 338.77
        Percent of CPU this job got: 98%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 5:42.81
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 520
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 181
        Voluntary context switches: 9978
        Involuntary context switches: 1216
        Swaps: 0
        File system inputs: 150160
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0



And this is really quite high. But… I think I have a more pressing issue with 
that BTRFS /home on an Intel SSD 320 and that is that it is almost full:

merkaba:~> LANG=C df -hT /home
Filesystem               Type   Size  Used Avail Use% Mounted on
/dev/mapper/merkaba-home btrfs  254G  241G  8.5G  97% /home

merkaba:~> btrfs filesystem show
[…]
Label: home  uuid: […]
        Total devices 1 FS bytes used 238.99GiB
        devid    1 size 253.52GiB used 253.52GiB path /dev/mapper/merkaba-home

Btrfs v3.12

merkaba:~> btrfs filesystem df /home
Data, single: total=245.49GiB, used=237.07GiB
System, DUP: total=8.00MiB, used=48.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=4.00GiB, used=1.92GiB
Metadata, single: total=8.00MiB, used=0.00



Okay, I could probably get back 1,5 GiB on metadata, but whenever I tried a 
btrfs filesystem balance on any of the BTRFS filesystems on my SSD I usually got 
the following unpleasant result:

Halve of the performance. Like double boot times on / and such.



So I have the following thoughts:

1) I am not yet clear whether defragmenting files on SSD will really bring a 
benefit.

2) On my /home problem is more that it is almost full and free space appears 
to be highly fragmented. Long fstrim times speak tend to agree with it:

merkaba:~> /usr/bin/time fstrim -v /home
/home: 13494484992 bytes were trimmed
0.00user 12.64system 1:02.93elapsed 20%CPU (0avgtext+0avgdata 768maxresident)k
192inputs+0outputs (0major+243minor)pagefaults 0swaps

3) Turning autodefrag on might fragment free space even more.

4) I have no clear conclusion on what maintenance other than scrubbing might 
make sense for BTRFS filesystems on SSDs at all. Everything I tried either did 
not have any perceivable effect or made things worse.

Thus for SSD except for the scrubbing and the occasional fstrim I be done with 
it.


For harddisks I enable autodefrag.


But still for now this is only guess work. I don´t have much clue on BTRFS 
filesystems maintenance yet and I just remember the slogan on xfs.org wiki:

"Use the defaults."

With a cite of Donald Knuth:

"Premature optimization is the root of all evil."

http://xfs.org/index.php/XFS_FAQ#Q:_I_want_to_tune_my_XFS_filesystems_for_.3Csomething.3E


I would love to hear some more or less official words from BTRFS filesystem 
developers on that. But for know I think one of the best optimizations would 
be to complement that 300 GB Intel SSD 320 with a 512 GB Crucial m5 mSATA SSD 
or some Intel mSATA SSDs (but these cost twice as much), and make more free 
space on /home again. For criticial data regarding data safety and amount of 
accesses I could even use BTRFS RAID 1 then. All those MPEG3 and photos I 
could place on the bigger mSATA SSD. Granted a SSD is definately not needed for 
those, but it is just more silent. I never got how loud even a tiny 2,5 inch 
laptop drive is, unless I switched one external on while using this ThinkPad 
T520 with SSD. For the first time I heard the harddisk clearly. Thus I´d prefer 
a SSD anyway.

Still even with that highly full filesystem performance is pretty nice here. 
Except for some burts on btrfs-delalloc kernel threads once in a while. 
Especially when I fill it even a bit more. BTRFS has trouble finding free space 
on this partition. I saw this thread being active for half a minute without 
much happening on BTRFS. Thus I really think its good to get it at least to 
20-30 GiB free again. Well I could still add about 13 GiB to it if I get rid 
of a 10 GiB volume for testing out SSD caching.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7