FSCK macht probleme (KILLED)

D

Dienstag

Member
Hallo Leute,

ich hatte ein problem mit einem externen hdd gehäuse und ich hab mir dadurch wohl das fs zerschossen. Ich hab die platte nun herausgenommen und intern angeschossen, kann sie aber nicht mehr mounten da:
WARNING: R/W mount of /mnt/meinePlatte denied. Filesystem is not clean - run fsck
Zum Vergrößern anklicken....
ich habe danach ein wenig mit fsck herumprobiert, am meisten erfolg hatte ich mit:
fsck_ufs -y /dev/da1p1
Zum Vergrößern anklicken....
der output sieht so aus:
** /dev/da1p1
** Last Mounted on /mnt/meinePlatte
** Phase 1 - Check Blocks and Sizes
Killed
Zum Vergrößern anklicken....
natürlich lässt sich die Platte danach immer noch nicht mounten :grumble:

Ich bin leider ein absoluter freebsd noob und weiss nicht wie ich das Killed deuten soll. Gibt es da ein logfile oder so? Es ist schon möglich das die platte selber auch schrott ist, aber ich würde schon gerne noch die daten retten. Leider ist aber auf der platte eigentlich nur eine vmdk datein, da ich freenas auf einem wmware esxi installiert habe. Ich kann also von aussen nichts machen.

Ich benutze übrigens freenas 0.72 liveCD und es handelt sich nicht um die system partition und das fs ist UFS, fsck sollte also eigentlich keine probleme machen.

Ich hoffe jemand weiss rat, besten dank schon mal im voraus.
 
Killed heißt dem Programm wurde ein Signal geschickt, dass es sich vorzeitig beenden soll.

Hast du CTRL+C gedückt oder den Rechner heruntergefahren?
 
Ich kenne mich mit fsck nicht sonderlich gut aus, deswegen würde ich noch warten, bis einer unsere Experten Stellung dazu nimmt.

Vielleicht ist es möglich, die Partition readonly einzuhängen.
Code: 
mount -o ro -t ufs /dev/da1p1 /mnt/meinePlatte
Zuerste ein Plattenimage zu erstellen könnte auch hilfreich sein. (Falls dir deine Platte abraucht, oder fsck dein Dateisystem anknabbert.)
Code: 
dd if=/dev/da1 of=/mnt/vielplatz/backup.img
 
Hast du CTRL+C gedückt oder den Rechner heruntergefahren?
Zum Vergrößern anklicken....
nein, ich hätte gar nicht die zeit dafür gehabt, ausserdem wäre das ganz schön dumm von mir gewesen :D. "Killed" kommt direkt nachdem ich den befehl eingegeben habe, es wird also nicht erst etwas überprüft und dann abgebrochen.

Vielleicht ist es möglich, die Partition readonly einzuhängen.
Zum Vergrößern anklicken....
Hat leider nicht geklappt, aber immerhin gibt es jetzt eine neue Fehlermeldung:

Code: 
WARNING: /mnt/meinePlatte was not properly dismounted
/mnt/meinePlatte: mount pending error: blocks 292224 files 0
der ordner /mnt ist aber leer.

ich habs dann noch versuch mit:
Code: 
umount /dev/da1p1
aber der fehler bleibt derselbe.
 
hört sich nach hardwarefehler an... platte, controller, kabel oder ram
Zum Vergrößern anklicken....
Hm das wäre mühsam. Die platte selber scheint zwar noch zu funktionieren, da mein esxi server sie anscheinend ohne probleme mounten kann. Es kann aber gut sein, dass die "virtuelle hdd" kaputt gegangen ist. Diese vmware images sind ziemlich anfällig und ich glaube es gibt leider keinen guten weg um diese zu reparieren.
 
das ist jetzt nur geraten, aber:

- frage an dich: wie gross ist deine externe platte?
- frage an die freebsd-jungs: wieviele gigabyte schafft fsck_ufs maximal?

vielleicht erkennt fsck in der ersten phase dass die platte zu gross ist, und killt sich dementsprechend selbst. jemand mit zugriff auf den quellcode wird dir sicher nach einem

Code: 
% grep -r killed /usr/src/fsck/*

(oder sowas) mehr sagen koennen.
 
Hast Du es schon mal mit testdisk versucht? Ich weiß jetzt so nicht, ob das Programm in den Ports vorhanden ist. Notfalls den Rechner mit einer Knoppix oder partedmagic CD booten, da ist das Programm auf jeden Fall dabei.

Hat mir neulich auch mal bei einer Festplatte geholfen, wo mir der Rechner gesagt hat, die Platte wäre nicht formatiert.
 
dettus schrieb:
frage an die freebsd-jungs: wieviele gigabyte schafft fsck_ufs maximal?
Zum Vergrößern anklicken....
Kommt natürlich auf den RAM drauf an. Mal grob über den Daumen - und das ist wirklich grob, da die Anzahl der Inodes auf dem Dateisystem der entscheidende Punkt ist - braucht fsck ca. 400 Megabyte RAM pro 1TB Speicher. FreeBSDs fsck ist in den letzten Jahren wesentlich speichereffizienter geworden, auch unter dem Druck immer größerer RAID-Arrays.

Also fragen wir mal so: Wie groß ist das Dateisystem und wie viel RAM hat die Kiste?
 
Sorry leute, ich habe die platte gestern nacht schon wieder formatiert, da ich nicht länger warten konnte und ich eigentlich davon ausgegangen bin, dass die "virtuelle HDD" schrott ist.

Das problem mit den ram könnte aber sehr gut sein, die platte hatte 2TB und ich habe freenas glaub nur 256MB ram gegeben. Eigentlich hätte ich locker viel mehr freimachen können, aber ich hab darüber wirklich nicht nachgedacht und habe angenommen, das freenas locker mit soviel klar kommt.

Jedenfalls wäre es sicher gut wenn die entwickler von fsck eine warnung einbauen würden, falls man zu wenig ram hat oder so. Ich denke das sollte nicht ein alzu grosser aufwand sein.
 
Hallo Dienstag,

naja, mit 256MB kannst du heute kein Betriebssystem mehr begeistern. Meine letzten 8GB Ram haben 140EU gekostet. Unter 2GB würde ich keinen Rechner betreiben.


Gruß ré
 
naja, mit 256MB kannst du heute kein Betriebssystem mehr begeistern. Meine letzten 8GB Ram haben 140EU gekostet. Unter 2GB würde ich keinen Rechner betreiben.
Zum Vergrößern anklicken....
Da hast du natürlich recht, aber in meinem fall ging es ja um ein freenas, welches nicht gerade sehr viel leisten muss. Und gerade bei *nix derivate kommt man mit sehr wenig ram aus, wenn man keine grafische oberfläche installiert hat. Ich hab z.B. ein debian 6 am laufen, welches immerhin zwei webinterfaces zur verfügung stellt und dieses braucht gerade mal 138MB ram.

hier findet man folgendes:

192MB of RAM is the minimum required for starting the Full platform.
256MB of RAM is the minimum required for upgrading the Embedded platform of versions > 0.7.
Using advanced features like software RAID 5 and enabling lots of functions may need more RAM (512MB or more).
For using ZFS, we recommend a minimum of 1 GB RAM and using the FreeNAS release for 64bit processors.

soviel auch zum thema ZFS ;)
 
ja, das sind _minimum_ Angaben, mein Router hat 128MB RAM und nutzt davon nur 16MB. aber der hat auch nur 256MB HDD. Bei 2TB würde das auch anders aussehen ;-)

Gruß ré
 
na, ich denke unser neuling hat da aber einen wichtigen punkt angesprochen.
vielleicht koennte wirklich mal jemand die fsck-entwickler anschreiben und denen sagen dass die meldung "killed" bei zu wenig speicher nicht hilfreich ist.

steht jemand von euch vielleicht schon auf der passenden mailingliste?
 
@kira12
wie gesagt, ich sehe auch ein, dass es ein wenig knapp war. Aber du musst auch verstehen dass es viele leute gibt, die ein nas mit so wenig ressourcen wie möglich betreiben wollen. Dies vor allem aus kosten gründen, aber auch wegen dem stromverbrauch. Mir ist natürlich klar, dass RAM nicht gerade die grössten stromfresser sind :D

Ich würde von daher ein freenas nicht unbedingt mit einem normalen freebsd vergleichen, ich denke die haben sicher wert darauf gelegt, dass man eben nur sehr wenig ram braucht. 256 MB ist eigentlich auch nicht wirklich wenig. Ich meine damit kannst du ein XP betreiben.

Es spielt aber eigentlich keine grosse Rolle, wenn ich nicht schon formatiert hätte, hätte ich es gerne mit mehr RAM versucht. Es ist ja schlussendlich nicht ganz sicher, dass es wirklich daran lag, oder gibt es irgendwo min spezifikationen für fsck? Das wäre ansonsten sicher auch noch wichtig, dass man sowas vielleicht sogar in die man pages aufnimmt.

Könntest du mir aber mal erklären warum man für grössere HDD's auch mehr RAM braucht? Mir ist da der zusammenhang nicht ganz klar. Das ein tool wie fsck da probleme macht, ist nicht weiter erstaunlich, da es ja das ganze zeug auf der platte cashen muss. Aber ich denke auch hier wäre es zumindest technisch möglich das ganze auch mit weniger RAM zu realisieren. Es würde wahrscheinlich einfach der performance massiv zusetzen ;)
 
Naja, bekommt fsck denn überhaupt mit, weshalb er gekillt wird? Ich dachte nun, dass er einfach die Limits des Kernel überschreitet, sobald er keinen neuen Speicher mehr liefern kann, gibt es ein SIGKILL...
 
Dienstag schrieb:
Könntest du mir aber mal erklären warum man für grössere HDD's auch mehr RAM braucht? Mir ist da der zusammenhang nicht ganz klar.
Zum Vergrößern anklicken....
Ganz einfach. fsck muss gewisse Dinge im Gesamtüberblick betrachten und kopiert diese in den RAM. Je größer die Platte ist, umso größer sind die Datenstrukturen auf ihr und je mehr RAM wird benötigt. Wie ich schon sagte, ist fsck schon wesentlich speichereffizienter geworden. Zu Zeiten von FreeBSD 6 benötigte man pro Terabyte Speicher im Dateisystem ca. 1GB RAM und das wurde entsprechend dann irgendwann recht eklig... Nun scheint aber das Maximum an Optimierungsbedarf erreicht zu sein. Da man bei FreeBSD 9 dank "Journaled Softupdates" das fsck nach einem Absturz oder Stromausfall nicht mehr zwingend benötigt, denke ich, dass es akzeptabel ist.
 
Hallo Leute,

aber weil wir gerade bei dem Thema sind, bringt ZFS auf dem Desktop gegenüber UFS+S (Geschwindigkeits)vorteile? Natürlich unter genug RAM und schnelle CPU? Macht es da aus einen Unterschied zwischen SSD und HDD?

Gruß ré
 
Moin kira12,

kira12 schrieb:
Hallo Leute,

aber weil wir gerade bei dem Thema sind, bringt ZFS auf dem Desktop gegenüber UFS+S (Geschwindigkeits)vorteile? Natürlich unter genug RAM und schnelle CPU? Macht es da aus einen Unterschied zwischen SSD und HDD?

Gruß ré
Zum Vergrößern anklicken....

Geschwindigkeitsvorteile sicher nicht, da der Verwaltungsaufwand bei ZFS höher ist, als bei UFS. Datensicherheit hat halt ihren Preis;)
Man muss allerdings zwischen Read-Access und Write-Access unterscheiden, aber netto betrachtet ist ZFS langsamer als UFS, unabhängig von der Storage-Hardware.

JueDan
 
troll schrieb:
Schlägt dann nicht einfach die Allokation fehl?
Zum Vergrößern anklicken....
Theoretisch ja, natürlich. Praktisch nicht unbedingt. malloc() schlägt fehl, wenn die entsprechende Menge Speicher nicht mehr bereitgestellt werden kann. Werden aber zusätzlich Maximalwerte überschritten, wie z.B. limits(1) sie angibt oder der Kernel sie beim Boot in kern.maxdsize festlegt, gibt es ein SIGKILL. Ganz einfach um zu verhindern, dass ein amoklaufender Prozess das ganze System lahmlegt.

Außerdem: Wenn das System so knapp an Speicher ist, dass es aus welchen Gründen auch immer Prozesse abschießen muss, wählt FreeBSD den unglücklichen Prozess aus, der als letzter Speicher angefordert hat. Damit erwischt er meist einen sehr dicken Brocken. Linux hingegen wählt zufällig einen Prozess aus und schießt den ab. In jedem Fall gibt's nenn Eintrag im Systemlog: "Out of memory: Killed process 12345"
 
juedan schrieb:
Moin kira12,



Geschwindigkeitsvorteile sicher nicht, da der Verwaltungsaufwand bei ZFS höher ist, als bei UFS. Datensicherheit hat halt ihren Preis;)
Man muss allerdings zwischen Read-Access und Write-Access unterscheiden, aber netto betrachtet ist ZFS langsamer als UFS, unabhängig von der Storage-Hardware.

JueDan
Zum Vergrößern anklicken....

Hallo Jürgen,

danke für die Erleuchtung ;-)

Gruß ré
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben