Am Montag, 7. Mai 2012 schrieb Martin Steigerwald: > Am Sonntag, 6. Mai 2012 schrieb Ilya Dryomov: > > On Sun, May 06, 2012 at 01:19:38PM +0200, Martin Steigerwald wrote: > > > Am Freitag, 4. Mai 2012 schrieb Martin Steigerwald: > > > > Am Freitag, 4. Mai 2012 schrieb Martin Steigerwald: […] > > > merkaba:~> btrfs balance start -musage=0.8 / > > > Invalid usage argument: 0.8 > > > merkaba:~#1> btrfs balance start -musage=700M / > > > Invalid usage argument: 700M > > > > > > > > > When I try without usage I get the old behavior back: > > > > > > merkaba:~#1> btrfs balance start -m / > > > ERROR: error during balancing '/' - No space left on device > > > There may be more info in syslog - try dmesg | tail > > > > > > > > > merkaba:~> btrfs balance start -musage=1 / > > > Done, had to relocate 2 out of 13 chunks > > > merkaba:~> btrfs balance start -musage=1 / > > > Done, had to relocate 1 out of 12 chunks > > > merkaba:~> btrfs balance start -musage=1 / > > > Done, had to relocate 1 out of 12 chunks > > > merkaba:~> btrfs balance start -musage=1 / > > > Done, had to relocate 1 out of 12 chunks > > > merkaba:~> btrfs filesystem df / > > > Data: total=10.00GB, used=7.34GB > > > System, DUP: total=32.00MB, used=4.00KB > > > System: total=4.00MB, used=0.00 > > > Metadata, DUP: total=1.00GB, used=586.41MB > > > > Btrfs allocates space in chunks, in your case metadata chunks are > > probably 512M in size. Naturally, having 586M busy you can't make > > that chunk go away, be it with or without auto-reclaim and usage > > filter accepting size as its input. > > Hmmm, whatever it did tough: I believe I had the BTRFS performance go > down by a big margin by my playing around. > > I didn´t to any measurements yet, but apt-cache search could so much > slower as well as starting Iceweasel. The SSD tends to feel quite a bit > more like a harddisk. (It still feels faster tough.) > > And startup time has also raised: > > martin@merkaba:~> systemd-analyze > Startup finished in 6058ms (kernel) + 9285ms (userspace) = 15344ms > > This has been about 8,5 seconds before. > > I can´t prove that this is due to a slower BTRFS, but I highly suspect > it. > > So I think I learned that there is no guarentee that a BTRFS balance > improves the situation at all. It seemed to have worsened it a lot. > > Well it was just my experimenting around. I didn´t have a real problem > before and now I seemed I have to created me one. > > Now I wonder whether there would be a way to fix up the perceived > performance regression except of creating a new logical volume with > BTRFS, copying all the stuff to it and switching / to use the new > volume.
I did it the redo the filesystem way: merkaba:~> systemd-analyze Startup finished in 6602ms (kernel) + 4246ms (userspace) = 10848ms Thats not the about 8.5 I seen already, but it was the first start after activating inode_cache + space_cache, as I didn´t want to activate it on GRML 2011.12 3.1 kernel. The filesystem has been mounted with compress=lzo from the beginning. Which also made in space usage. Also Iceweasel and apt-cache are way faster now again. Almost instant. Next time I use an other BTRFS filesystem than my / one for experiments with balancing ;). Thanks, -- 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
