btrfs "kein Speicherplatz mehr" beim mounten

T

Traceman

New Member
Hallo,

ich habe ein größeres Problem mit einer Partition mit btrfs. Wenn ich sie mounten will kommt die Meldung:

Code: 
mount: Einhängen von /dev/sdx1 auf /var/... ist fehlgeschlagen: Auf dem Gerät ist kein Speicherplatz mehr verfügbar

Das Dateisystem ist aber nur halb voll:

Code: 
# btrfs fi show
Label: none  uuid: 93353b88-8c0c-4e18-b036-951f967a499f
        Total devices 1 FS bytes used 726.66GiB
        devid    1 size 1.46TiB used 1.46TiB path /dev/sdx1

Btrfs v3.17

Der Befehl "btrfs [filesystem] balance ..." geht aber nur bei einem gemountetem Volume.
Der Befehl "btrfs check --repair ..." bringt leider nichts, ebenso die mount-Option "recover", "cache_clear" und "nospace_cache".
Hinzufügen von mehr Speicher geht auch nur online.

Mehr Hinweise habe ich leider nicht gefunden.

Kann mir jemand noch helfen an meine Daten zu kommen? Bitte kein Hinweis auf ein Backup, das sind die Backup-Daten eines anderen Rechners.

Hardy
 
Die Hinweise aus dem Link helfen nicht wirklich weiter. Read-only geht es zwar, da spare ich mir die 700GB über die DSL-Leitung zu übertragen, aber schreiben geht immer noch nicht.

Warum soll btrfs für ein Backup nicht gehen? Es werden ja nur die neuen (veränderten) Dateien gespeichert, die unveränderten bekommen nur Hard-Links.

Eigentlich wollte ich noch einen Schritt weitergehen und lessfs einsetzten, dort wird btrfs für die volle Funktion benötigt.

Hardy
 
Warum soll btrfs für ein Backup nicht gehen?
Click to expand...
Weil es neu ist und noch so einige Bugs hat welche gelöst werden sollen bevor man sie produktiv, zumal auf einem System zur Absicherung anderer Systeme, einsetzen sollte.

Es werden ja nur die neuen (veränderten) Dateien gespeichert, die unveränderten bekommen nur Hard-Links.
Click to expand...
Warum willst du hier dann zwingend btrfs - ich tippe mal auf Kompression?
Sonst sehe ich nämlich gegenüber EXT4 keinerlei Vorteile bei rsync-Einsatz.

Eigentlich wollte ich noch einen Schritt weitergehen und lessfs einsetzten, dort wird btrfs für die volle Funktion benötigt.
Click to expand...
Zumal bei Backups würde ich eher auf erprobte Techniken zugreifen. Also ein EXT4 Dateisystem, Rsync und offline-Deduplikation durch Hardlinks. Zu letzterem siehe hier:
http://linux.die.net/man/1/fdupes

Read-only geht es zwar, da spare ich mir die 700GB über die DSL-Leitung zu übertragen, aber schreiben geht immer noch nicht.
Click to expand...
Potentiell ist es nicht möglich von einem vollen Dateisystem zu recovern solange du nicht weiteren Speicherplatz (1GB Usbstick reicht) bereitstellen kannst damit er fertig werden kann.
 
Naja die Snapshots sind für ein Backup System schon ziemlich genial und so mit Ext4 nicht umsetzbar. Hab selber einige Btrfs Backupserver laufen und die laufen ohne Probleme.
 
Naja die Snapshots sind für ein Backup System schon ziemlich genial und so mit Ext4 nicht umsetzbar.
Click to expand...
Die Leistungseinbuße eines LVM-Snapshots sind bei Backupserver generell irrelevant und deutlich weniger problematisch als unstabile Dateisysteme zu verwenden - zumindest imho.
Ich kann auf Backupserver mit 10 Platten (RAID-6) in Kombination mit LVM Thin volumes und Snapshots keinerlei Einbuße im Backup-Regelbetrieb feststellen; das Ding schreibt noch immer brav seine physikalische Grenze von ~500MB/s und auch random-io ist weiterhin sehr ordentlich.
 
d4f said:
Warum willst du hier dann zwingend btrfs - ich tippe mal auf Kompression?
Sonst sehe ich nämlich gegenüber EXT4 keinerlei Vorteile bei rsync-Einsatz
Click to expand...

Prüft btrfs nicht genauso wie ZFS nach jedem Schreibvorgang ob der Block auch richtig geschrieben worden ist? Das wäre auch jeden Fall ein Pluspunkt. Besteht immer noch der allgemeine Glaube das btrfs broken by design ist?
 
You must log in or register to reply here.
Back
Top