[Btrfs] Slechte performance*

[Jungian]

Ik ben redelijk nieuw met btrfs, na tijden zfs, xfs, ex3/4 en reiserfs gebruikt te hebben. Het valt mij dat mijn geconverteerde ext4 root-partitie VEEL meer metadata toegewezen krijgt

root@host:~# btrfs fi df /
Data: total=37.27GB, used=3.71GB
System: total=32.00MB, used=4.00KB
Metadata: total=18.60GB, used=1.48GB

dan het door mij, met standaardopties aangemaakte, btrfs fs (op een 4TiB disk):

root@host:~# btrfs fi df /opslag
Data: total=3.29TB, used=3.16TB
System, DUP: total=8.00MB, used=360.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=4.00GB, used=3.88GB
Metadata: total=8.00MB, used=0.00

Nu is het laatstgenoemde fs bespottelijk traag, wat waarschijnlijk komt omdat er erg weinig ruimte over is om metadata in weg te schrijven. Ik heb uiteraard het machtige orakel Google geraadpleegd, maar geen oplossingen kunnen vinden; wel iemand die hetzelfde probleem lijkt te hebben (maar zijn metadata size is VEEL groter): http://cd34.com/blog/scal...low-metadata-almost-full/.

Concreet mijn vragen:
1) Hoe kan het dat mijn geconverteerde partitie zoveel meer metadata-ruimte tot zijn beschikking heeft?
2a) Kan ik mijn fs nog forceren om meer ruimte toe te wijzen aan dit fs?
2b) Kan dit niet: hoe voorkom ik dit bizarre probleem als ik een nieuw fs aanmaak?

Zie mijn laatste post

[Jungian]

(per abuis geplaatst @ de HK)

[ Voor 6% gewijzigd door Jungian op 28-04-2013 16:26 ]

[Kees]

Schopje naar NOS dan

[H!GHGuY]

Kan het dit zijn:

In-place ext3/4 conversion

Btrfs can warp to fit unusual spatial layouts because it has very little metadata anchored in fixed locations. The btrfs-convert tool exploits this ability to do an in-place conversion of any ext[2,3,4] file system by nesting equivalent Btrfs metadata in its unallocated space. This produces a hybrid file system that can be mounted as either ext[2,3,4] or Btrfs. If mounted as a Btrfs, all the converted files are available and writeable in the default subvolume; the old ext[2,3,4] filesystem itself is made visible as a large sparse file (mountable as a read-only disk image) in separate subvolume that can be deleted to commit the conversion. If mounted as ext[2,3,4], the conversion is rolled back.

Bron: Wikipedia: Btrfs

Als alternatief kun je dit eens proberen:
https://btrfs.wiki.kernel..._I.27ve_got_lots_of_space

[ Voor 9% gewijzigd door H!GHGuY op 28-04-2013 19:33 ]

[Jungian]

H!GHGuY schreef op zondag 28 april 2013 @ 19:29:
Kan het dit zijn:
Bron: Wikipedia: Btrfs

Als alternatief kun je dit eens proberen:
https://btrfs.wiki.kernel..._I.27ve_got_lots_of_space

Het daar genoemde commando

$ sudo btrfs fi balance start -dusage=5 /mount/point

had ik al uitgevoerd op mijn storage-fs; dit had geen effect. Het punt dat ik probeerde te maken met de df-output van mijn andere, geconverteerde, fs is dat het dus wel mogelijk is dat er veel meer metadata-ruimte beschikbaar wordt gemaakt. Ik vind het bizar dat btrfs niet besluit meer metadata-ruimte beschikbaar te maken terwijl er nog voldoende vrije ruimte is om dat te realiseren. Dezelfde dataset heeft probleemloos op een btrfs RAID10-set van 4 2TB-disks gestaan tot gisteren.

Mocht er iemand nog een goed idee hebben dan hoor ik het graag, want zoals het nu staat kan ik helemaal niets met deze dataset (afgezien van lezen).

---

Ik heb het op de mailing list van btrfs nagevraagd. Mijn probleem had niets te maken met de hoeveelheid metadata-ruimte die toegewezen werd aan mijn volume. Ik kreeg als suggestie om naast mijn bestaande mount-opties ook de volgende opties te gebruiken:

inode_cache,space_cache,autodefrag

Dit heeft geholpen: de performance was weer prima. Aangezien ik weer in staat was om het volume te spammen met data groeide ook de hoeveelheid data en ook uiteindelijk de hoeveelheid toegewezen ruimte voor metadata; mijn probleem had niets met metadata starvation te maken.

[ Voor 27% gewijzigd door Jungian op 28-04-2013 22:15 ]

[begintmeta]

Ik had de afgelopen maand ook wat met BTRFS geexperimenteerd (met OpenSUSE 12.3 en Arch), maar na 2 keer een onherstelbare fout van het filesystem (een keer op de root en een keer op een /var partitie) wacht ik het weer even af.

De performance was verder prima trouwens, ik gebruikte alleen space_cache (en een keer ook compress=lzo) als aanvullende mount-optie.

[ Voor 4% gewijzigd door begintmeta op 30-04-2013 00:49 ]