UFS verkleinern?

ath0

Well-Known Member
Ich zöger jetzt seit ner weile mich an meinem Dateisystem zu schrauben. Mein Plan is eine zu 20 % belegte UFS Partition um ca 2% zu verkleinern, da ich eine swap Partition brauche. Ich habe im Netz und hier keine 100%ige aussage gefunden ob eine UFS Partition verkleinert werden kann. Aber einen Artikel im Handbuch der das Thema behandelt, ausführlich ist aber auch was anderes.
Ich muss die swap Partition einfrickeln weil ich einen Coredump haben will wenn mein System wieder mal zickt und ich Sie bei der Installation vergessen habe.

Habt Ihr evtl. eine Entscheidungshilfe für mich?
 
Nein, UFS kann nicht verkleinert werden. Das steht auf der Liste zu 10.0, aber ob es wirklch kommt, steht noch in den Sternen. Muss man mal schauen. Du musst also in jedem Fall das Dateisystem neu erstellen. Ich würde es so tun:

1. dump des Dateisystems in eine Datei: dump ... /dev/device | gzip | dd of=backup
2. Repartitioniere die ganze Geschichte
3. Restore auf das neue Dateisystem: cd /mountpoint ; gunzip -c backup | restore -rf -
 
Danke Yamagi!

Ich verstehe deine dämonen Verse zwar nicht (:D) aber ich habe meine platte schon mit dd kopiert und kopiere dann nur / sollte ja auch gehen :)

Ich verstehe das dd in dieser Zeile nicht würde gzip nicht eh eine Datei anlegen?

Code:
dump ... /dev/device | gzip | dd of=backup
 
Mit dd kopierst du das gesamte. ... Bit für Bit... Auch den leeren Space. Somit wirst du beim rückspielen merken, dass dein Zieldevice zu klein ist (du hast es ja verkleinert).
 
ath0 schrieb:
Ich verstehe das dd in dieser Zeile nicht würde gzip nicht eh eine Datei anlegen?
Ja, würde es. Das dd(1) ist einer meiner Ticks. Ich bin aus bitterer Erfahrung auf diversen unixoiden Systemen (FreeBSD zählte nicht dazu) einfach recht paranoid, was das korrekte Ausschreiben von Binärdaten aus Pipes betrifft.
 
@Rakor Danke für den Hinweis, beim zurück spielen hatte gedacht cp zu nutzen.
Mir kommt aber gerade die Frage ob mein mbr nach dem neu partitionieren noch in Takt ist. Notfalls dd ich den aus dem Dump :D
Ja ich weiß ist ganz schönes gefrickel was ich da mach, war aber auch anders geplant:mad:

@Yamagi Und wieder bin ich ein Stück schlauer :)

Ich denke ich habe jetzt einen Plan. Danke für die Hilfestellungen!

ath0
 
Zuletzt bearbeitet:
Wenn du über cp kopierst achte darauf, dass deine Rechte, Flags und User-Zurordnung erhalten bleiben... ebenso etwaige Links.... ich finde dd immer problematisch für Backup-Zwecke... evtl ist es sicherer die Daten dann durch eine dump-restore-pipe zu kopieren....
 
Ja, würde es. Das dd(1) ist einer meiner Ticks. Ich bin aus bitterer Erfahrung auf diversen unixoiden Systemen (FreeBSD zählte nicht dazu) einfach recht paranoid, was das korrekte Ausschreiben von Binärdaten aus Pipes betrifft.

Welches OS ist denn so buggy, dass es die Ausgabeumleitung von Binärdatein beschädigt?
 
Bei mir war's eine steinalte HP-UX Version. Ich hoffe, dass es inzwischen auch dort gefixt ist.
 
1. dump des Dateisystems in eine Datei: dump ... /dev/device | gzip | dd of=backup

Zwischenfrage:
habt ihr verschiedene Performance/Schreibgeschwindigkeit wenn ihr
Code:
dump ... /dev/device | gzip | dd of=backup
mit

Code:
dump ... /dev/device | gzip -c > backup

vergleich? Oder wie handhabt ihr z.B. dd und die Blocksize Option bs= ?
 
du brauchst also eine SWAP-Partition? Ich kenne mich mit solchen Dumps nicht aus, aber wenn es dir langt, diese nach dem nächsten Systemstart noch auslesen zu können, dann sollte es doch vielleicht auch eine SWAP-Datei tun. Beinahe scheint mir das so.
Alternativ würde ich in so einem Sonderfall einen USB-Stick nehmen und es damit versuchen. Keine Ahnung, ob das gelingt, aber probieren...

OK.
Deine Sicherung der Platte mit dd willst du mit CP zurückspielen und das bedeutet, dass du dieses "Image" mounten musst. Das sollte kein wirklich großes Problem sein (nunja, ganz trivial ist es auch nicht). Ist das aber gemountet, hast du das Filesystem eingebunden und da spielt der MBR dann keine Rolle mehr. Das bedeutet, du brauchst da nicht mehr dran zu schrauben.
Alternativ zu cp nehme ich immer rsync, das viel bessere cp! wenn du mich fragst.
 
Hallo pit234a eine swap Datei habe ich, die hab ich damals als "vorläufige" Lösung angelegt und benutze sie seit dem. Nach dem mein Rechner beim Start immer wieder gemeckert hat, dass das device nicht zum dumpen genutzt werden kann, habe ich mal genauer gelesen und in man dumpon folgendes gefunden

Code:
Since a panic(9) condition may occur in a situation where the kernel can‐
not trust its internal representation of the state of any given file sys‐
tem, one of the system swap devices, and not a device containing a file
system, should be used as the dump device.

Und seit dem will ich eine swap Partition anlegen.
Ob ein usb Stick in diesem Fall langen würde wäre aber auch einen versuch wert.
Bin mir nicht sicher ob darauf noch zugegriffen werden kann wenn der Kernel Panik bekommt, das ist Erstmal besser als den Karren komplett neu zu partitionieren.

Ich glaube du hast mir das Wochenende gerettet Danke :)
 
da bin ich mal gespannt, ob es funktioniert.
Immerhin kann ja auch von USB gebootet werden, deshalb denke ich, dass es schon sehr früh unterstützt wird. Ob es bei deinem Problem funktioniert, wirst du sehen.
Ich hatte geglaubt, der Hauptgrund für SWAP als Ort zum Dumpen sei, dass dies dann ausgelesen werden kann, wenn das System nicht "wirklich gebootet" ist, also etwa im Single-User-Mode. Wenn ein Dump im Betrieb passiert, hätte ich erwartet, daß auch ein File genutzt werden kann. Dies liegt ja eigentlich nicht im Dateisystem selbst.
Naja. wie gesagt kenne ich mich damit nicht aus, ich habe das nämlich noch nie gebraucht und könnte wohl auch den Dump nicht lesen und deuten.

GENERIC dumped nicht, oder?
 
Was versprichst du dir vom coredump?
Ohne dir zu nehe treten zu wollen, erstaunt mich, dass du bei deinem Wissensstand ein coredump debuggen willst.
Ich will dich ganz sicher nicht angreifen, aber gehst du hier nicht ein Risiko ein, um ein ungewisses Ergebnis zu bekommen?
 
Das geht immer soweit ich das weiß. Generic enthält sogar debugsymbole wodurch das erkunden eines solchen Dumps erst sinnvoll wird, wenn es so funktioniert wie ich mir das vorstelle :o
 
Was versprichst du dir vom coredump?
Ohne dir zu nehe treten zu wollen, erstaunt mich, dass du bei deinem Wissensstand ein coredump debuggen willst.
Ich will dich ganz sicher nicht angreifen, aber gehst du hier nicht ein Risiko ein, um ein ungewisses Ergebnis zu bekommen?

Sorry das ich erst jetzt antworte, hatte nicht gesehen das noch ein Post rein gepurzelt ist.

Ich verspreche mir von einem coredump meinen Fehler zu finden. Das mir der coredump evtl. auch nicht hilft, da ich nicht genug im Kernel drin stecke ist mir bewusst. Mein Wissen ist definitiv ausbaufähig, aber ich habe es bis hier her geschafft und möchte weiter lernen :)
Welches Risiko meinst du?
 
Ich verspreche mir von einem coredump meinen Fehler zu finden. Das mir der coredump evtl. auch nicht hilft, da ich nicht genug im Kernel drin stecke ist mir bewusst. Mein Wissen ist definitiv ausbaufähig, aber ich habe es bis hier her geschafft und möchte weiter lernen :)
Welches Risiko meinst du?

Hehe, das war definitiv die bestmögliche Antwort auf meine Frage. :)
Mit Risiko mein ich Datenverlust bei der ganzen Rumfrickelei im Dateisystem. Ich gehör zu der erzkonservativen Sorte, was solche Sachen betrifft.
Aber die Bedenken haben sich eh erledigt, weil ich von flaschen Vorraussetzungen ausgegangen war. Ich hatte gedacht, dass es dir in erster Linie darum geht die Abstürze loszuwerden. Du willst aber zusätzlich wissen, was die Abstürze verursacht.
 
Hm, ich hätte da noch eine Idee:
das Dump Device lässt sich ja auch einstellen.
Falls kein Platz auf der Systemplatte oder SSD vorhanden ist, könnte man doch auch etwa als Sparlösung einen USB-Stick als Dump Device verwenden.
Hier gibt es Infos zum Konfigurieren:
http://www.freebsd.org/doc/de/books/developers-handbook/kerneldebug.html
.. und weiter in den Manual Pages:
http://www.freebsd.org/cgi/man.cgi?query=rc.conf&sektion=5
man rc.conf(5) schrieb:
dumpdev (str) Indicates the device (usually a swap partition) to
which a crash dump should be written in the event of a system
crash. If the value of this variable is ``AUTO'', the first
suitable swap device listed in /etc/fstab will be used as
dump device. Otherwise, the value of this variable is passed
as the argument to dumpon(8). To disable crash dumps, set
this variable to ``NO''.

dumpdir (str) When the system reboots after a crash and a crash dump
is found on the device specified by the dumpdev variable,
savecore(8) will save that crash dump and a copy of the ker-
nel to the directory specified by the dumpdir variable. The
default value is /var/crash. Set to ``NO'' to not run
savecore(8) at boot time when dumpdir is set.

savecore_flags
(str) If crash dumps are enabled, these are the flags to pass
to the savecore(8) utility.
Also USB-Stick als Swap formatieren müsste doch eigentlich möglich sein.
 
@Fusselbär Ich habe das mit dem USB Stick jetzt auch gemacht, anscheinend mag FreeBSD das nicht sonderlich, ich bekomme jetzt bei jedem zweiten (reproduzierbar) ausschalten "quasi shutdown -p now" eine panic wie im Bild zu sehen. Im laufenden Betrieb ist aber alles gut solange der swap nicht genutzt wird läuft alles Flüssig, wird der swap dann benötigt, wird man zur Kaffee-Pause gezwungen. Sehr sozial wie ich finde :D

Ich wollte jetzt noch gucken ob das Problem der panic nicht doch eher die Mischung aus swap Datei und swap Partition ist bevor ich das weiter verfolge, das wird diese Woche aber eher nichts :(

Edit:
Achso, auch nach mehr als 6h Wartezeit ist kein coredump zu finden obwohl der Stick kräftig blinkt. Da der Swap ja eigentlich auch schon weg ist, halte ich das mal für richtig.
 

Anhänge

  • kernel_panic.jpg
    kernel_panic.jpg
    1,8 MB · Aufrufe: 383
Das ist die "swapoff"-Panik. Die tritt ab und an auf, wenn eine Swap entfernt wird. Immer tritt sie auf, wenn ein Swap-Device verschwindet. Sie ist bekannt und sollte in der nächsten Zeit behoben werden... Dann gibt's wie in 8.x keine Panic mehr, stattdessen verschwindet die Swao einfach aus dem System.
 
Was bloß, wenn da tatsächlich was draufgeswappt war? Werden die betroffenen Prozesse dann abgeschossen?
 
Zurück
Oben