Re: speeding up slow btrfs filesystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Samstag, 17. Dezember 2011 schrieb Sergei Trofimovich:
> On Fri, 16 Dec 2011 21:58:45 +0100
> 
> Martin Steigerwald <Martin@xxxxxxxxxxxx> wrote:
> > Nope. Doesn´t seem to help much.
> > 
> > How to turn it off, after turning it on?
> > 
> > deepdance:~> LANG=C mount -o remount,datacow /
> > mount: / not mounted already, or bad option
> 
> In debian you can disable syncing on per-process basis:
>     http://packages.debian.org/sid/eatmydata
> 
> $ eatmydata apt-get install foo
> $ eatmydata firefox
> $ eatmydata liferea
> 
> makes things more bearable

I am not ready to accept that this is the proper answer to what I 
experience. Applications using fsync() are realistic real world scenarios 
and I think BTRFS has to cope with that.

Yesterday I upgraded the laptop to 3.2-rc4. After converting the inode 
cache the filesystem appeared to be faster, but I have to wait for some 
Debian packages to pile up on the repository servers to get a real 
impression.

I think I will scrub / balance / defragment the filesystem after a backup. 
But I am not sure in what order.

I understand that defragment defragments files. But then what does balance 
do? For RAID setup I have seen it distributing data evenly across drives 
when I echo > /sys/block/sda/[…]/delete a drive before and BTRFS had to 
distribute unevenly cause of that. But what does it do on a filesystem on a 
single drive? I bet it would balance out trees? Will it resize trees with 
lots of unused space as well?

According to

deepdance:~> btrfs filesystem df / 
Data: total=11.23GB, used=6.98GB
System, DUP: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=1.86GB, used=511.35MB
deepdance:~> btrfs filesystem show
[…]
Label: 'debian'  uuid: 2bf5b1dc-1d89-4f0d-a561-1a5551a27275
        Total devices 1 FS bytes used 7.48GB
        devid    1 size 15.00GB used 14.97GB path /dev/dm-0

Btrfs Btrfs v0.19

the filesystem might have had some chances to fragment heavily, cause the 
tree sizes add up almost to the 15 GB of space available.

I also remember that for some time the filesystem was nearly full which 
would explain the tree sizes.

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux