Warum können gemountete (nicht logische) Partitionen zur Laufzeit nicht skaliert / verschoben werden?

2762
Senkaku

Bei der Suche, warum es nicht möglich ist, die Größe einer bereitgestellten Partition zu ändern, habe ich meistens Antworten wie diese gefunden:

  • Es hängt vom Dateisystem und der Partition ab. Verschiedene Betriebssysteme und Partitionen verwenden unterschiedliche Methoden. - von Javier Rivera

  • Zuerst müssen Sie das zugrunde liegende Blockgerät erweitern. Wenn Sie eine herkömmliche Partition auf einer einzelnen Festplatte verwenden, ist dies nicht möglich. LVM und mdadm können das Blockgerät erweitern. Anschließend können Sie resize2fs ausführen, um die fs zu erweitern (vorausgesetzt, es ist ext [234]). - von psui

  • Das hängt wirklich von dem Dateisystem ab, das Sie [...] verwenden, aber es wird NICHT empfohlen, die Größe einer bereitgestellten, nutzbaren Partition zu ändern. - von Luis Alvarado

Non erklärt, warum es nicht möglich ist (weil niemand gefragt hat), nur erwähnt, dass es vom Dateisystem abhängt oder überhaupt nicht möglich ist, wenn die Partition kein logisches Volume ist.

Ich habe überhaupt keine Kenntnis über die inneren Abläufe des Mount-Prozesses und der Handhabung von Partitionen / Dateisystemen eines Betriebssystems, aber ich frage mich, warum das Partitionierungsprogramm den Benutzer nicht dazu auffordern kann, alle seine Prozesse zu schließen und danach zu halten die verbleibenden Prozesse und eine Kopie der Daten, die sie im RAM benötigen, und heben die Bereitstellung der Partition auf, um deren Größe zu ändern.

3
+1. Das Betriebssystem weiß jedoch nicht, welche Daten die Prozesse benötigen, und viele Programme mögen keine ganzen Partitionen, deren Dateisysteme ihnen unter den Füßen gerissen werden. Und der Linux-Kernel kann nicht wirklich umgehen und den Benutzer zur Eingabe auffordern. Abgesehen von der Tatsache, dass viele Linux-Systeme, die hauptsächlich aus Einzelbenutzern bestehen, X ausführen und jede Kernel-Eingabeaufforderung bestenfalls nicht gesehen werden kann. Der Kernel selbst sollte niemals unter normalen Umständen direkt mit dem Benutzer interagieren. Benutzermodus-Software sollte mit dem Kernel interagieren. a CVn vor 10 Jahren 1

2 Antworten auf die Frage

3
Rod Smith

Eigentlich ist es ist möglich, viele modernen Dateisysteme, um die Größe, während sie montiert sind (obwohl in der Regel nur dann, wenn ihre Größe zu erhöhen). Zum Beispiel:

  • From man resize2fs: "Das Programm resize2fs ... kann verwendet werden, um ein nicht angehängtes Dateisystem zu vergrößern oder zu verkleinern ... Wenn das Dateisystem eingehängt ist, kann es dazu verwendet werden, die Größe des eingehängten Dateisystems zu vergrößern ..."
  • From man xfs_growfs: "Das Dateisystem muss eingehängt sein, um gewachsen zu sein."
  • Von man mount: „Mount - Optionen für JFS ... = Größe ändern Wert ... Größe ändern die Lautstärke Wert Blöcke JFS unterstützt nur ein Volumen wachsen, nicht schrumpfen..“
  • Von BTRFS Fun : "Und ja, es handelt sich um eine Online-Größenänderung. Es ist nicht notwendig, umzusteigen / zu verkleinern / zu montieren. Also keine Ausfallzeiten!"

AFAIK, ReiserFS kann nicht geändert werden, wenn es gemountet wird.

Die Fähigkeit, die Größe eines Datenträgers zu ändern, ohne dessen Bereitstellung aufzuheben, ist äußerst wichtig für geschäftskritische Server und dergleichen. Ein Webhosting-Anbieter (beispielsweise) kann sich die erforderliche Ausfallzeit nicht leisten, um ein Dateisystem offline zu schalten, um die Größe nach dem Hinzufügen eines Servers zu ändern neue Festplatte in ein RAID-Array. Deshalb unterstützen so viele moderne Dateisysteme diese Funktion.

Das bedeutet, dass GParted die Größe von Partitionen nicht ändern kann, ohne sie aufzuheben. Ich bin nicht positiv, vermute aber, dass dies mehr mit der Partitionsseite der Gleichung zu tun hat als mit dem Dateisystem; oder es könnte sein, dass die GParted-Entwickler konservativ waren und die Anforderungen an den kleinsten gemeinsamen Nenner (nämlich für ReiserFS) festlegten.

Das Ändern der Größe von Dateisystemen ist definitiv einfacher, wenn sie in einem LVM-Setup gespeichert werden. Diese Art der Konfiguration bedeutet, dass Sie niemals den Startpunkt eines Dateisystems verschieben müssen, sodass Sie ein logisches Volume und das darin enthaltene Dateisystem bei Bedarf Dutzende Male in den Speicherbereich der vorhandenen Dateisysteme verschieben können aber das hast du gelöscht. LVM wurde auch für dynamische Änderungen der logischen Datenträger konzipiert, während die Partitionsverarbeitung im Kernel statischer ist. Wenn Sie häufig Ihre Dateisysteme anpassen, sollten Sie sich unbedingt mit LVM befassen. LVM bietet eine gewisse Lernkurve, aber es lohnt sich für jeden, der fortgeschrittene oder häufige Dateisystemmanipulationen durchführt.

2
Shi

Dateisysteme implementieren einige Kernel-API. Sie müssen also Funktionen bereitstellen, um eine Datei anhand des Namens zu öffnen, in eine Datei zu schreiben, aus einer Datei zu lesen und eine Datei wieder zu schließen (halten Sie sich an diese grundlegenden Vorgänge).

Der Kernel bietet Funktionen zum Lesen eines Sektors und zum Schreiben eines Sektors.

Das magische Dazwischen wird vom Dateisystem "Treiber" ausgeführt. Wenn ein Programm also eine Datei öffnen möchte, übergibt der Kernel diese Anforderung an den Dateisystemtreiber. Der Treiber liest dann die Dateisystem-Metadaten und findet den Eintrag für die Datei. Der Eintrag enthält Informationen zum Dateisystem, z. B. Besitz von Benutzern und Gruppen, Berechtigungen, Zugriffszeit und vieles mehr, und natürlich Informationen zu dem Sektor, in dem sich die Datei auf der Festplatte befindet (lassen Sie uns die Fragmentierung hier ignorieren).

Wenn Sie also die gesamte Partition an eine andere Stelle auf der Festplatte verschieben, haben alle gespeicherten Sektornummern jetzt einen Versatz, aber das Dateisystem kennt diesen Versatz nicht. Wenn ein Programm dann versucht, eine Datei zu öffnen, verwendet das Dateisystem die in den Metadaten des Dateisystems gespeicherte Sektornummer, um den Inhalt der Datei zu lesen. Da das gesamte Dateisystem jedoch um mehrere Sektoren verschoben wird, entsprechen die gelesenen Daten nicht dem Dateiinhalt und die Datei ist beschädigt. Gleiches gilt für alles andere im Dateisystem.

Der Kernel weiß nichts davon. Ein Treiber fordert zum Lesen eines Sektors auf. Der Kernel weiß nicht, ob die Sektornummer einen Offset haben soll oder nicht. Dies ist also etwas, das in allen Dateisystemtreibern implementiert werden muss.

Stellen Sie sich nun ein (altes) Dateisystem vor, das 16 Bit verwendet, um Sektoren zu adressieren. Nehmen wir an, ein Sektor hat 512 Bytes. Die maximale Größe des Dateisystems kann daher 32 MiB betragen. Wenn Sie das Dateisystem weiter erweitern möchten, muss es die Größe eines adressierbaren Sektors von 512 Byte auf 1024 Byte ändern. Aber auch jetzt ist das Dateisystem voll, da alle Sektornummern verwendet werden. Das Dateisystem-Erweiterungsprogramm muss also alle Dateien scannen und zwei Sektoren, die 1024 Bytes groß sind, aber nur 512 Bytes verwendet, in einen Sektor kopieren, sodass ein Sektor (wieder) voll ist und der andere freigegeben werden kann.

Nun stellen Sie sich vor, dass dies getan werden muss, während das Dateisystem eingehängt ist und Programme glücklich von und zur Festplatte lesen und schreiben. Dies führt zu einer gewissen Komplexität des Dateisystemtreibers, die nur für diesen speziellen Anwendungsfall erforderlich ist. Daher ist es einfacher, ein Dateisystem nur zu ändern, wenn es nicht eingehängt ist.

Außerdem gibt es mehr Magie unter der Haube. Sie können beispielsweise eine Datei erstellen, öffnen und entfernen. Die Datei hat keine Repräsentation mehr im Dateisystem (sie hat keinen Dateinamen). Da jedoch noch ein offener Deskriptor vorhanden ist, kann die Datei immer noch gelesen und beschrieben werden. Wenn das Programm den Deskriptor enthält fork, können sogar die Kinder auf diese Datei zugreifen, wenn sie den Deskriptor erben. Sobald alle für diese Datei geöffneten Deskriptoren d sind close, werden die Sektoren vom Dateisystem als nicht verwendet gekennzeichnet und können für neue Dateien verwendet werden.

Wenn Sie also unmountdas Dateisystem und dann mountwieder, sind diese Dateien weg. Und das Programm steht fest.

Your answer is gorgeous, it answers a lot of questions I had, not just the one I asked above, but there is one detail in your example I do not understand. `[...] it has to change the size of an addressable sector from 512 bytes to 1024 bytes.` Wouldn't that overwrite every second sector, or at least the information that there were originally two sectors of the size of 512 byte and not one with 1024 byte for every two? Senkaku vor 10 Jahren 0

Verwandte Probleme