Hi!
Today I converted my /home from Ext4 to BTRFS by reformatting and copying
all over again.
I created the filesystem with -l 16384 -n 16384 -d single -m single on an
logical volume Intel SSD 320 and mount with compress=lzo,spacecache. Current
state:
merkaba:~> btrfs filesystem show
failed to read /dev/sr0
Label: 'home' uuid: […]
Total devices 1 FS bytes used 191.98GB
devid 1 size 223.52GB used 193.02GB path /dev/dm-2
[…]
merkaba:~> btrfs filesystem df /
Data: total=14.01GB, used=9.98GB
System: total=4.00MB, used=4.00KB
Metadata: total=776.00MB, used=573.20MB
Works well so far and I see no issues.
Except for a highly fragmenting file:
martin@merkaba:~/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend>
ls -lh
insgesamt 1,2G
-rw------- 1 martin martin 1,3G Jan 31 14:07 soprano-virtuoso.db
-rw-r--r-- 1 martin martin 14 Jan 31 14:06 soprano-virtuoso.lck
-rw------- 1 martin martin 0 Jan 27 17:52 soprano-virtuoso.lock
-rw-r--r-- 1 martin martin 13K Jan 31 10:22 soprano-virtuoso.log
-rw-r--r-- 1 martin martin 0 Jan 27 17:52 soprano-virtuoso.pxa
-rw-r--r-- 1 martin martin 8,0M Jan 31 14:07 soprano-virtuoso-temp.db
-rw-r--r-- 1 martin martin 14K Jan 31 14:07 soprano-virtuoso.trx
martin@merkaba:~/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend>
sudo filefrag soprano-virtuoso.db
[sudo] password for martin:
soprano-virtuoso.db: 481 extents found
[…]
martin@merkaba:~/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend>
sudo btrfs filesystem defragment
soprano-virtuoso.db
martin@merkaba:~/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend#20>
sudo filefrag soprano-
virtuoso.db
soprano-virtuoso.db: 481 extents found
[…]
martin@merkaba:~/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend>
sync
martin@merkaba:~/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend>
sudo filefrag soprano-virtuoso.db
soprano-virtuoso.db: 57 extents found
martin@merkaba:~/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend>
sudo filefrag soprano-virtuoso.db
[sudo] password for martin:
soprano-virtuoso.db: 3946 extents found
martin@merkaba:~/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend>
sudo filefrag soprano-virtuoso.db
soprano-virtuoso.db: 15143 extents found
martin@merkaba:~/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend>
martin@merkaba:~/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend>
sudo filefrag soprano-virtuoso.db
soprano-virtuoso.db: 15900 extents found
Now I do not perceive any bottle neck so far and this is an SSD.
What would be your recommendation: Add autodefrag to mount options or not?
For now I am inclined to let it run that way and see how it goes. I am a bit
reluctant about autodefrag cause of the additional writes it causes.
Well, a direct dd of the file to memory is still quite fast:
merkaba:/home/martin/.kde/share/apps/nepomuk/repository/main/data/virtuosobackend>
echo 3 >
/proc/sys/vm/drop_caches; LANG=C dd if=soprano-virtuoso.db of=/dev/null bs=1M
1322+0 records in
1322+0 records out
1386217472 bytes (1.4 GB) copied, 5.34167 s, 260 MB/s
Another database is the Akonadi database, but I am using PostgreSQL for this at
the moment which tends to use lots of (smaller) files and due to KDE PIM from
KDE SC 4.4.11 still in Debian, there is no mail metadata in it, just contacts
and
calendar metadata.
Ciao,
--
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
