DSM 6.x und darunter Defragmentierung - BTRFS Volume läuft voll

[*Bossi]

Hallo zusammen,

ich habe auf meiner TS-415+ im Speicher-Manager unter Volume->Verwalten die Dateisystem Defragmentierung gestartet, welche mit BTRFS zur Verfügung steht.

Auf meinem Volume habe (hatte) ich 6,91 von 7,85 TB belegt.

Anfangs lief noch alles gut, dann nach etwa einer halben Stunde bekam ich die Fehlermeldung "Volume 1 is running out of space" und es waren 7,63 von 7,85 TB belegt.
Dann ist der Speicherplatz innerhalb von Minuten randvoll gelaufen (7,85 von 7,85 TB) belegt.

Nun schlägt das NAS permanent Alarm, mit diversen Fehlermeldungen, z.B. dass keine Snapshots mehr ausgeführt werden können u.s.w.

Habe keine Möglichkeit gefunden die Defragmentierung abzubrechen, bzw. würde ich mich auch nicht trauen weil ich nicht weiß was dann passiert.

Hatte schon mal jemand so einen Fehler?
Was würdet Ihr empfehlen außer abwarten in der Hoffnung dass sich das Problem "von selbst" löst?
Bin mir auch nicht sicher ob die Defragmentierung überhaupt noch läuft, mangels freiem Speicher auf dem Volume...

 

[Thonav]

Hi Bossi,
wie hast Du denn die Snapshots konfiguriert? Alle gemeinsamen Ordner? Mit welcher Häufigkeit? Keine Panik, das bekommen wir schon hin...

Habe für meine Systeme (alle btrfs) ebenfalls Snapshot im Einsatz und da ist der Speichermehrverbrauch nicht von Relevanz.

 

[*Bossi]

Hallo Tonav,

lasse von allen gmeinsamen Ordner Snapshosts erstellen.
Je nachdem wie oft sich Daten in dem Freigabeordner ändern und wie "wichtig" die Daten ist die Häufigkeit und Anzahl der Snapshots unterschiedlich.
Die Snapshots waren aber nie ein Problem und haben auch nie viel Speicherplatz belegt, da ja nur Änderungen erfasst werden.

Mein Problem besteht nun darin, dass die Defragmentierung (welche nun übrigens abgeschlossen ist), den Speicher hat vollaufen lassen.
Habe nach der Defragmentierung nun 0 Byte freien Speicherplatz.

 

[Thonav]

Merkwürdig. Habe noch nie gehört, dass die Datendefragmentierung Speicherplatz verbraucht... Habe es gestern bei meinen DS´en mal durchlaufen lassen und der Speicherverbrauch hat sich zu keiner Zeit verändert.
Würde jetzt mal ein paar Minuten warten - kann ja sein, dass der Speicherplatz neu berechnet wird.

 

[*Bossi]

Warten hat nichts geholfen, auch ein Neustart nicht.
Nach der seit dem Defragmentieren ist und bleibt der Disk-Speicher zu 100% belegt :-(

 

[Thonav]

Sehr merkwürdig. Sind denn Änderungen in der Filestation zu erkennen?

 

[mehlbox]

Du kannst versuchen ein balance zu starten.

btrfs balance start -v -dusage=0 /volume1

Die Zahl 0 nach jedem Durchlauf um 5 oder 10 erhöhen (bis 100).
Je größer die Schritte desto länger dauert es.

 

[Thonav]

Nur für mein Verständnis, mehlbox. Was bewirkt dieses "balance"?

 

[PsychoHH]

Soweit mir bekannt werden damit die Daten/Files neuverteil bzw. geordnet, geht aber glaub ich nur bei Raid.

 

[mehlbox]

BTRFS teilt sich das Dateisystem in Blöcke ein. Sobald ein Block auf "allocated" steht ist der Platz für das Linux Betriebssystem vollständig belegt. BTRFS hat aber eine eigene Sichtweise vom freien Speicherplatz. Jedes dieser Blöcke kann nur halb voll sein.. oder nur zu 10% gefüllt.
Mit "btrfs balance start -v -dusage=10 /volume1" würdest du BTRFS anweisen, Blöcke die nur zu 10% oder weniger befüllt sind zusammenzufassen.

Ich würde sagen wenn du bei 20 angekommen bist und noch immer keinen freien Speicher hast dann sind die Blöcke nicht dein Problem.

Hab Hier: https://docs.oracle.com/cd/E37670_01/E37355/html/ol_use_case1_btrfs.html
das gefunden

Defragmenting a file or a subvolume that has a copy-on-write copy results breaks the link between the file and its copy. For example, if you defragment a subvolume that has a snapshot, the disk usage by the subvolume and its snapshot will increase because the snapshot is no longer a copy-on-write image of the subvolume.

Bedeutet für mich.
Du musst deine snapshots löschen.

 

[*Bossi]

Ich habe jetzt alle Snapshots gelöscht und der Speicherplatz steht wieder zur Verfügung.

In meinen Augen ein Bug, dass Snapshots die eigendlich keinen bis wenig Speicherplatz verbrauchen, nach der Defragmentierung plötzich das gesammte Volume fluten...

Vor der Defragmentierung alle Snapshots löschen, kann ja auch nicht die Lösung sein, man hat die Snapshos ja nicht zum Spaß, sondern benötigt die unter umständen noch.

Werde mal versuchen ob der Fehler reproduzioerbar ist, und das dann mal an Synology melden.
Hoffe dass die den Fehler dann schnell beheben können!

 

[mehlbox]

Ich würde nicht von einem Bug sprechen. Es liegt eigentlich in der Natur eines COW Dateisystem dass die Dateien nur noch als Fragmente vorliegen weil ja mehrere Dateien auf den selben Speicherbereich referenzieren.
Man kann COW auch abschalten. Dann hat man aber viele Vorteile von BTRFS abgeschaltet.

Die Frage bleibt ob der Leistungszuwachs nach einer Defragmentiertierung einem wirklich was bringt oder man lieber den Komfort von Snapshots nutzt und mit einem Fragmentiertem Dateisystem leben kann.

 

[Simon88]

Es ist so erbärmlich, dass das Problem über 3,5 Jahre später immer noch besteht.
Nach einem Defrag hatte ich 700 GB weniger, macht man danach sofort wieder ein Defrag, wirds noch weniger - ohne jegliche Änderungen - keine Datei mehr oder weniger !

Ursache ist ein Bug im Kernel
"Warning: Defragmenting with Linux kernel versions < 3.9 or ? 3.14-rc2 as well as with Linux stable kernel versions ? 3.10.31, ? 3.12.12 or ? 3.13.4 will break up the reflinks of COW data (for example files copied with cp --reflink, snapshots or de-duplicated data). This may cause considerable increase of space usage depending on the broken up reflinks."

https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-filesystem

Abhilfe schafft nur das Löschen sämtlicher Snapshots, doch 100% genau so viel Speicherplatz wie vor dem Defrag hat man trotzdem nicht.
Das ist doch einfach nur lächerlich, dass Synology das Problem nicht auf die Reihe bekommt.
Der Synology-Support stellt sich dumm und schiebt das Problem auf den Anwender, um das mal freundlich auszudrücken !

 

[ottosykora]

also erstens wenn es bekannt ist , warum tut jemand trotz Warnungen diesen Defrag starten? Eine Warnung erscheint doch ganz klar. Und wenn jemand trotz Warnung dies tut, was soll man dann sagen, ist nicht villeicht der schuld der den Knopf gedrückt hat?

Und ich verstehe nicht ganz was genau was hat Synology damit zu tun wenn der Linux Kernel selber das Problem ist? BTRFS als Filesystem ist doch nicht von Synology erfunden worden.

 

[Simon88]

tut tut ...
Weil man nicht dumm jede Information / Vermutung glauben sollte, sondern diese erst einmal verifizieren muss. Zudem fand ich die Aussage von kernel.org erst nach meinen Tests, was meine Ergebnisse somit bestätigte.
Aber in der heutigen Gesellschaft muss man sich über solche Aussagen nicht mehr wundern. Geglaubt wird ohne das Hirn einzuschalten alles was irgendwo ein Mensch in den Netzwerken postet.
Gibt es in den IT-Foren eigentlich nur noch Leute, die superschlau daherreden, aber keinen Plan davon haben, weil das Problem offensichtlich noch nie selbst gehabt ?

Zudem ist das
"Die Volume-Auslastung könnte sich erhöhen, wenn das Volume Schnappschüsse von freigegebenen Ordnern enthält." von
https://www.synology.com/de-de/know...rageManager/volume_filesystem_defragmentation
sehr unspezifisch und somit alles relativ.

Das können 5 / 50 / 5000 / 50000 MB sein - wer rechnet schon mit 700 GB.

Du glaubst doch zudem nicht ersthaft, dass Leute von Synology bei der Kernel-Entwicklung nicht auch beteiligt sind oder dort etwas zu sagen hätten. Wenn die wollten, könnten die ordentlich Druck ausüben.
Ansonsten, ist es egal wer das Problem löst - es muss aber gelöst werden.
Jeder verwendet btrfs hauptsächlich WEGEN Snapshots und gerade das ist ein Problem - somit ein Widerspruch in sich und spricht nicht gerade für ein ausgereiftes Dateisystem.
Wer nicht wegen Snapshots muss, sollte daher auf btrfs verzichten !

Ob sozusagen der Zulieferer das Problem verursacht oder der Hersteller selbst spielt keine Rolle - das Problem muss Synology lösen oder andere dazu zwingen es zu tun.
Man kann das Problem jedenfalls nicht Jahre ignorieren ! Ein Produkt besteht heutzutage immer aus 99% Zulieferer-Bauteilen ob nun Software oder Hardware.

 

[Fusion]

Bei neueren DS hat Synology ja auch den kernel aktualisiert. Was sie sonst noch alles backporten etc weiß man auch nicht. Direkter Vergleich mit vanilla-kernel ist also nicht immer gegeben.

Leider gibt es keine gute Übersicht, wo dies der Fall ist.
Da die DS918+ z.B. schon mit Kernel 4.4.x unterwegs ist.

Auf der 415+/216+II ist es 3.10.105
Lasse grad spaßeshalber mal wieder ein Defrag auf meinem btrfs Volume (1 von 4 volumen) auf der DS415+ laufen.

 

[Simon88]

Danke für den ersten themenbezogenen Beitrag.
Ich selbst habe hier eine DS1815+ - Updates gab es noch vor nicht allzu langer Zeit - jedenfalls noch nicht Jahre her.
Habe mich noch nie damit beschäftigt wie lange und in welchem Umfang man noch Support leistet.
Die Kernel-Problematik mit btrfs gibt es aber mindestens schon 3,5 Jahre - also kommt da nix mehr und das ist allerhand.
Leider gibt es für die DS1815+ immer noch keinen Ersatz - somit könnte ich nicht einmal auf ein neues Modell mit ggf. neuerem Kernel umsteigen, selbst wenn ich wollte.
2 NAS oder NAS + Erweiterung ist einfach nicht drin, so viel Geld sehe ich absolut nicht ein.

Interessant ist halt der riesen Unterschied
Bei einem Volume mit über 100 Snapshots machte es nur 16 GB aus, beim anderen Volume mit nur 3 Snapshots aber 700 GB.
Nach dem Löschen und neu erstellen der 3 Snapshots waren es aber immer noch 122 GB mehr als vorher - Rest wurde binnen Minuten wieder freigegeben.
Das erstere Volume ist um den Faktor 3,5 kleiner. 16 GB vs. 700 GB wegen Defrag zusätzlich belegtem Speicherplatz ist somit erstaunlich.

Der Rest hat wohl wieder mit Blocks zu tun, der nächsten Mist von btrfs - selbst jeder mit 10% belegte Block benötigt 100%.
Kopiert man dann weiter Daten drauf, wird zwar erst einmal kein weiterer Speicherplatz mehr verbraucht bis alles zu 100% voll ist, aber man weiß so nie exakt wieviel Speicherplatz man noch hat - da man nicht weiß wieviel Blöcke nur minimal belegt sind.
Das ist auch der Grund, warum man btrfs defragen muss - man hört gerade bei großen Dateien, wie sehr sich das NAS die Daten zusammensuchen muss.
Nachdem 14 TB Festplatten nicht gerade günstig sind, defragmentiere ich lieber als durch die Sucherei schnellere Ausfälle zu haben.

 

[NSFH]

Weiter oben wurde geschrieben, dass Defrag keinen Speicherplatz braucht. Das Gegenteil ist der Fall.
Der schnellste defrag Mode funktioniert durch das Zusammenfassen von Dateien ausserhalb des benutzten Bereichs, dafür wird je nach Ggrösse der Dateien sogar recht viel Speicherplatz benötigt. Wie andes sollte man sonst zB ein 4GB Videofile zusammenbauen?
Hat Defrag das File zusammengesetzt muss es anschliessend noch den passenden Speicherplatz freimachen, bevor das File wieder an sdeinen neuen Platz kann.
Im übrigen ist es eine Todsünde einen Server bis zum Stehkragen voll laufen zu lassen. Mit zunehmender Speicherknappheit steigen die Fehlermeldungen in den Logdateien. Am Schluss schreibt sich der Server selber damit zu und nichts geht mehr.

 

[Synchrotron]

Nach meinem (laienhaften) Verständnis ist eine Fragmentierung von Dateien bei Ablage auf einem Serverlaufwerk in einem RAID „not a Bug, but a Feature“.

Durch die verteilte Ablage wird eine große Datei schneller gelesen und bereit gestellt, als wenn sie kompakt an einer einzigen Stelle liegen würde. Kein Laufwerkscache faßt mehrere GB - hier nutzt Linux bekanntlich freien RAM als Zwischenspeicher, um Schreib-/Leseprozesse zu Puffern. Die Laufwerke liefern ihre „Bröckchen“ dorthin, der Controller setzt sie zusammen und liefert sie im Netzwerk ab. Das heißt Fragmentierung ist ein Merkmal solcher Dateisysteme und dient dazu, sie performanter zu machen.

Die permanente Defragmentierung ist ein Relikt von Windows-PCs, die da völlig anders ticken. Seit fast alle primären (System-)Laufwerke heute SSDs sind, ist die Zeit auch vorbei.

Daher ist es durchaus berechtigt, wenn bei einer Syno eine Speicherplatz-Warnung kommt, obwohl noch „gigantische“ GB-Zahlen als frei angezeigt werden. Wie hier im Thread schon schön beschrieben, bricht ein Server deutlich früher ein, als der nackte Restspeicher zu sagen scheint. In so einer Situation kann Defragmentieren tatsächlich die Aktion sein, die die Performance endgültig killt.

 

[Simon88]

Durch eine Defragmentierung wird deshalb noch lange kein RAID5 oder sonst was aufgelöst.
Die Dateien sind immer noch auf diversen Platten verteilt und somit eine schnellere Lesegeschwindigkeit bzw. eben Sicherheitsaspekte.
Wobei das alles Theorie ist, denn mehr als um die 100 MB / Sek. wird dein LAN nicht schaffen, die Synology schon gar nicht.
Link-Aggregation hilft bei der Laien-Hardware Zuhause auch nicht weiter.
Ohne 10 GBit LAN nutzt du nicht einmal die Datenübertragungsrate einer einzigen Festplatte aus.
Die Defragmentierung sorgt jedenfalls dafür, dass nicht hier 100 KB liegen, woanders 1 MB und der Rest sonst noch tausendfach verteilt und der Schreib- / Lesekopf deshalb ständig hin- und herspringen muss.
Und noch einmal, btrfs ist das einzige Dateisystem unter Linux / Unix bei dem eine Defragmentierung nicht ohne Grund angeboten wird. Wäre es unnötig, gäbe es diese Möglichkeit im Synology NAS schlicht nicht wie bei anderen Dateisystemen eben auch.