• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

BTRFS - kein komplettes balance möglich, immer enospc

J

Jochen-of-Borg

Member
Hallo!

Ich verzweifle etwas an BTRFS. Es ist mir unmöglich, ein full balance durchzuführen. Ich laufe immer in eine disk full Fehlermeldung.
Es geht hier nicht um das bekannte Problem, dass ein balance wegen einem "vollen" Dateisystem erst gar nicht anläuft. Es läuft wunderbar, aber eben nie bis zum Ende.

Egal ob ich mich mit -dusage in 1%-Schritten langsam hoch hangel, oder ein vollständiges rebalance mache, gegen Ende bricht btrfs mit disk full ab. (ERROR: error during balancing '/mnt/pool/': No space left on device)

Beim letzten balance Versuch lief es sage und schreibe 7 Tage(!) lang bis zum enospc. Beim letzen Blick (Stunden vorher) waren noch 7% übrig, das Problem trat also wirklich erst gegen Ende auf.
Hat jemand eine Idee, was ich tun kann? Ich würde wirklich gerne wenigstens ein einziges Mal ein balance vollständig durchlaufen lassen. Das muss doch irgendwie möglich sein...

Hier meine Systemdaten:
openSUSE Leap 42.2, 64 bit
Kernel 4.4.36-8
btrfsprogs 4.5.3-3.1

Das BTRFS-Volume besteht aus 6 (verschlüsselten) Festplatten verschiedener Größen, als BTRFS RAID 5 Verbund

Hier noch ein paar Daten, geschossen direkt nach dem gescheiterten 7-tägigen balance Durchlauf:

Code: 
# btrfs fi sh /mnt/pool/ 
Label: 'Datengrab'  uuid: [unwichtig]
        Total devices 6 FS bytes used 9.79TiB
        devid    1 size 2.73TiB used 2.44TiB path /dev/mapper/truecrypt3
        devid    2 size 1.82TiB used 1.66TiB path /dev/mapper/truecrypt2
        devid    4 size 2.73TiB used 2.54TiB path /dev/mapper/truecrypt4
        devid    5 size 3.64TiB used 2.66TiB path /dev/mapper/truecrypt1
        devid    6 size 3.64TiB used 2.66TiB path /dev/mapper/luks1
        devid    7 size 931.51GiB used 641.28GiB path /dev/mapper/luks2
Code: 
# btrfs fi df /mnt/pool/
Data, RAID5: total=9.91TiB, used=9.77TiB
System, RAID5: total=80.00MiB, used=924.00KiB
Metadata, RAID5: total=15.06GiB, used=12.91GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

Code: 
# df -h /mnt/pool/
Filesystem              Size  Used Avail Use% Mounted on
/dev/mapper/truecrypt3   16T  9.8T  3.1T  77% /mnt/pool

Auszug von "journalctl _TRANSPORT=kernel" beim Abbruch:
Code: 
May 03 05:59:46 c64 kernel: BTRFS info (device dm-7): relocating block group 49867182833664 flags 129
May 03 06:00:21 c64 kernel: BTRFS info (device dm-7): found 56 extents
May 03 06:01:03 c64 kernel: BTRFS info (device dm-7): found 56 extents
May 03 06:01:26 c64 kernel: BTRFS info (device dm-7): relocating block group 49866109091840 flags 129
May 03 06:02:01 c64 kernel: BTRFS info (device dm-7): found 83 extents
May 03 06:03:03 c64 kernel: BTRFS info (device dm-7): found 83 extents
May 03 06:03:11 c64 kernel: BTRFS info (device dm-7): 216 enospc errors during balance
 
Gräfin Klara

Gräfin Klara

Hacker
du und df unter btrfs funktionieren nicht, sind also keine Referenz !

btrfs kann snapshots (speichert Daten Blöcke als backup) . Wahrscheinlich ist das der Grund.

Kopiere hierher ein paar Zeilen von:

Code: 
# snapper list

siehe dazu auch
https://wiki.archlinux.org/index.php/Snapper
 
OP
J

Jochen-of-Borg

Member
Gräfin Klara schrieb:
btrfs kann snapshots (speichert Daten Blöcke als backup) . Wahrscheinlich ist das der Grund.
Zum Vergrößern anklicken....

Snapshots?! OMG, daran hab ich gar nicht mehr gedacht.

Ich hatte in der Tat noch eine Kopie von einem read-only-Snapshot von einem anderen Volume drauf. BTRFS hat ja schon tolle Features, schade dass sie noch nicht alle richtig funktionieren... :D

Ich hab sie jetzt mal gelöscht, und probiere es nochmal. Danke für den Tipp!
Ich melde mich wieder mit dem Ergebnis. Bin ja mal gespannt...
 
M

marce

Guru
Wg, der tollen Features: Ist der Raid-5-Teil von BTRFS inzwischen stable?

... noch bis vor ca. 6 Monaten haben selbst die Entwickler davon abgeraten, das zu vewenden...
 
OP
J

Jochen-of-Borg

Member
marce schrieb:
Wg, der tollen Features: Ist der Raid-5-Teil von BTRFS inzwischen stable?
Zum Vergrößern anklicken....

Wohl eher nicht, nein.
So kann etwa bei einem Stromausfall das Volume evtl. dauerhaft auf read-only bleiben. Aber ich hab eine USV, und no risk, no fun. :D

Im ernst, der Single Modus ohne RAID ist mir bei einem Volume mit mehreren HDDs zu riskant. Dann lieber ein RAID 5 mit Bug-Risiko. Einen Tod muss man sterben... ;)
 
M

marce

Guru
Nein, muss man nicht. Der Trick heißt "Datensicherung" - neudeutsch auch als "Backup" bekannt.

Ich würde kein Feature verwenden, von dem die Entwickler selbst abraten...
 
OP
J

Jochen-of-Borg

Member
Also, auch ohne Snapshots geht es noch immer nicht. :(

Beim letzten Blick vorhin war es noch bei 3% Rest, jetzt hat er wieder abgebrochen.
Das positive: ohne die Snapshots dauert das balance nur noch halb so lange... (bis zum Abbruch)

:censored:

Code: 
# dmesg

[328957.616722] BTRFS info (device dm-8): relocating block group 56674985443328 flags 129
[328996.773030] BTRFS info (device dm-8): found 25 extents
[329065.051939] BTRFS info (device dm-8): found 25 extents
[329098.921058] BTRFS info (device dm-8): relocating block group 56019097747456 flags 129
[329123.022617] BTRFS info (device dm-8): found 18 extents
[329193.140841] BTRFS info (device dm-8): found 18 extents
[329221.490551] BTRFS info (device dm-8): 81 enospc errors during balance

marce schrieb:
Nein, muss man nicht. Der Trick heißt "Datensicherung" - neudeutsch auch als "Backup" bekannt.
Zum Vergrößern anklicken....

Ein RAID ist kein Ersatz für ein Backup, ist bekannt. Darum geht es mir hier aber nicht.
 
Gräfin Klara

Gräfin Klara

Hacker
Ich habe dich oben um ein
# snapper list
gebeten. Da hätte man vor dem Start eines erneuten balancing einiges sehen können. Leider ignorierst du das ..

Egal

Wenn es die snapshots nicht sind, dann werden es wohl die Metadaten sein.
btrfs füllt beim Balancing Säcke unterschiedlicher Größe. Ist der kleinste Sack voll, dann bricht btrfs ab, egal wie viel
im größten Sack noch Platz ist. Einige finden dieses Verfahren super, ich bin der Meinung, es schafft nur Probleme.

Wenn also der Sack mit den Metadaten voll ist (weil z.B. nicht ausbalanciert), die ja im Grunde nur FS Informationen darstellen,
dann meldet sich btrfs mit "no space left" ab.
Versuche ein
# btrfs fi df // oder so ähnlich
dort sollte unter "Metadata DUP" die Situation erkennbar sein

Gruß
Gräfin Klara
 
OP
J

Jochen-of-Borg

Member
Gräfin Klara schrieb:
Ich habe dich oben um ein
# snapper list
gebeten. Da hätte man vor dem Start eines erneuten balancing einiges sehen können. Leider ignorierst du das ..
Zum Vergrößern anklicken....

Sorry, ich dachte, das hätte sich mit dem löschen von den Snapshots erledigt.

Code: 
# snapper list
Type   | #   | Pre # | Date                     | User | Cleanup | Description           | Userdata
-------+-----+-------+--------------------------+------+---------+-----------------------+--------------
single | 0   |       |                          | root |         | current               |
single | 1   |       | Tue Jan 31 18:35:21 2017 | root |         | first root filesystem |
single | 2   |       | Tue Jan 31 19:10:13 2017 | root | number  | nach der Installation | important=yes
pre    | 199 |       | Sat May  6 21:29:52 2017 | root | number  | zypp(y2base)          | important=yes
pre    | 209 |       | Sat May  6 22:51:36 2017 | root | number  | zypp(zypper)          | important=yes
post   | 210 | 209   | Sat May  6 23:07:58 2017 | root | number  |                       | important=yes
pre    | 212 |       | Wed May 10 17:21:51 2017 | root | number  | yast sw_single        |
pre    | 213 |       | Wed May 10 17:23:34 2017 | root | number  | yast apparmor         |
post   | 214 | 213   | Wed May 10 17:23:44 2017 | root | number  |                       |
pre    | 215 |       | Wed May 10 17:29:08 2017 | root | number  | zypp(y2base)          | important=no
post   | 216 | 215   | Wed May 10 17:32:57 2017 | root | number  |                       | important=no
pre    | 217 |       | Wed May 10 17:39:01 2017 | root | number  | yast services-manager |
post   | 218 | 217   | Wed May 10 17:44:10 2017 | root | number  |                       |
pre    | 219 |       | Wed May 10 17:45:18 2017 | root | number  | zypp(y2base)          | important=no
post   | 220 | 219   | Wed May 10 17:45:23 2017 | root | number  |                       | important=no
post   | 221 | 212   | Wed May 10 20:29:48 2017 | root | number  |                       |

Das dürfte sich aber alles auf das alles auf meine Systemplatte beziehen. Auf meinem Datenvolume sollten keine Snapshots mehr sein, schon gar nicht von Snapper.

"btrfs subvolume list" zeigt mir nur zig Subvolumes auf '/' an, aber keines auf '/mnt/pool/', um das es hier geht.


Wenn also der Sack mit den Metadaten voll ist (weil z.B. nicht ausbalanciert), die ja im Grunde nur FS Informationen darstellen,
dann meldet sich btrfs mit "no space left" ab.
Versuche ein
# btrfs fi df // oder so ähnlich
dort sollte unter "Metadata DUP" die Situation erkennbar sein
Zum Vergrößern anklicken....

Sollte nicht spätestens so weit am Ende des balance nicht wieder genug Platz freigeräumt sein?

Code: 
# btrfs filesystem df /mnt/pool/
Data, RAID5: total=9.92TiB, used=9.79TiB
System, RAID5: total=80.00MiB, used=808.00KiB
Metadata, RAID5: total=15.23GiB, used=12.89GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

Code: 
# btrfs filesystem usage /mnt/pool/
WARNING: RAID56 detected, not implemented
WARNING: RAID56 detected, not implemented
WARNING: RAID56 detected, not implemented
Overall:
    Device size:                  15.46TiB
    Device allocated:                0.00B
    Device unallocated:           15.46TiB
    Device missing:                  0.00B
    Used:                            0.00B
    Free (estimated):                0.00B      (min: 8.00EiB)
    Data ratio:                       0.00
    Metadata ratio:                   0.00
    Global reserve:              512.00MiB      (used: 0.00B)

Data,RAID5: Size:9.92TiB, Used:9.79TiB
   /dev/mapper/luks1       2.40TiB
   /dev/mapper/luks2     928.83GiB
   /dev/mapper/truecrypt1          2.40TiB
   /dev/mapper/truecrypt2          1.82TiB
   /dev/mapper/truecrypt3          2.40TiB
   /dev/mapper/truecrypt4          2.40TiB

Metadata,RAID5: Size:15.23GiB, Used:12.89GiB
   /dev/mapper/luks1       3.23GiB
   /dev/mapper/luks2       2.64GiB
   /dev/mapper/truecrypt1          3.23GiB
   /dev/mapper/truecrypt2          2.89GiB
   /dev/mapper/truecrypt3          3.23GiB
   /dev/mapper/truecrypt4          3.23GiB

System,RAID5: Size:80.00MiB, Used:808.00KiB
   /dev/mapper/luks1      16.00MiB
   /dev/mapper/luks2      16.00MiB
   /dev/mapper/truecrypt1         16.00MiB
   /dev/mapper/truecrypt2         16.00MiB
   /dev/mapper/truecrypt3         16.00MiB
   /dev/mapper/truecrypt4         16.00MiB

Unallocated:
   /dev/mapper/luks1       1.23TiB
   /dev/mapper/luks2      27.75MiB
   /dev/mapper/truecrypt1          1.23TiB
   /dev/mapper/truecrypt2         27.75MiB
   /dev/mapper/truecrypt3        332.96GiB
   /dev/mapper/truecrypt4        332.96GiB

Hilft das weiter?
 
Gräfin Klara

Gräfin Klara

Hacker
Jochen-of-Borg schrieb:
Sollte nicht spätestens so weit am Ende des balance nicht wieder genug Platz freigeräumt sein?
Zum Vergrößern anklicken....

Ja, das ist richtig, aber ich hatte folgenden Verdacht.
btrfs bindet sich an die UUID. So ist es z.B. nicht möglich, das FS auf ein andere Platte zu übertragen.
Du hast in der Zwischenzeit ja schon einiges herumprobiert und das btrfs mit luks header im truecrypt mode
am mapper erzeugt. mkfs.btrfs .. /dev/mapper/blahblah... löscht aber keine Metadaten wenn vorhanden. D.h. es könnten Metadaten mit alter UUID vorhanden sein. Das wären dann Leichen, mit denen du in ein enospc fährst. Ich weiß auch nicht, ob du mit cryptsetup ein --offset für einen eventuell ultrageheimen key gesetzt hast. Auch das könnte dieses Problem verursachen.

> Metadata, RAID5: total=15.23GiB, used=12.89GiB
Sieht aber nicht so aus, es war nur ein Verdacht.
Oben habe ich geschrieben: "Metadata, DUP". Das ist natürlich falsch, du hast ja RAID5.

Jochen-of-Borg schrieb:
Hilft das weiter?
Zum Vergrößern anklicken....
Leider nein. Ich habe auf Grund deiner Angaben es auch wie hier für RAID-5 angegeben
https://btrfs.wiki.kernel.org/index.php/FAQ#Understanding_free_space.2C_using_the_original_tools
durchgerechnet. Ich kann kein Problem erkennen.

Was du da vorhast, ist NICHT trivial.
Wäre es möglich - nur zum Test - auf dm-crypt (oder was immer du verwendest) zu verzichten und deinen pool ohne mapper direkt auf die devices zu legen?
Einfach nur um ein mögliches Problem im Kernel zwischen devices < crypt > mapper auszuschließen?
Dein Vorhaben ist ja auch ohne diesen Layer und mit diesem wackeligen btrfs eine Herausforderung.
Schritt für Schritt, meine ich.

Gruß
Gräfin Klara
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben