[linux-l] Neues Root-Dateisystem

[Frank]

Hallo!
>> Mir gehts hauptsächlich ums booten. Und das mache ich ziemlich oft....
>>     
>
> naja, da wird wohl kein fs besonders hervorstechen. Dabei wird ja fast
> ausschließlich gelesen. Hier sind wohl Plattenzugriffszeiten oder Netzwerk
> (NFS) wichtiger. Man kann den Bootvorgang natürlich enorm beschleunigen,
> indem man sich einen angepaßten Kernel strickt und so gut wie alles, was da
> automatische Erkennung von Hardware heißt, abschaltet. Mein alter PII 400MHz
> bootet schneller oder mindestens genau so schnell (die Platten sind recht
> langsam) wie mein P4 2.x GHz Notebook mit Debian-Default Kernel.
>   
Soll das heißen... das wäre ja ungeheuerlich... nein, wirklich? 
Übertreibst du da wirklich nicht? Ich meine, es wär natürlich 
supermegatoll, wenn das wahr wäre aber es klingt echt zu schön um wahr 
zu sein. Nimmst du dann noch ein optimierteres "init" (wie zum Beispiel 
Init-NG) als das standardmäßige "sys V" (schreibt man das so?)?
> Vielleicht hilft es dir auch, wenn du nur deswegen so häufig bootest, weil
> du den Rechner ausschaltest, wenn du ihn nicht mehr brauchst, mal
> Hibernate/Suspend-To-Disk zum Laufen zu bringen. Das stellt dir dann
> (vorausgesetzt es funktioniert richtig) deine Xsession auch gleich wieder
> mit her. (Mit manchen Grafikkarten gibt es da wohl Probleme.)
>   
Tja, ich habe ein IBM Thinkpad T23, und die Dinger sollen sich sich ja 
einwandfrei in den Ruhezustand schicken lassen. Nur meins nicht. :-( Und 
zwar hab ich mir extra eine primäre FAT32-Partition angelegt (Typ: 
Hidden FAT16), dann mit tphdisk eine Hybernatedatei angelegt, die größer 
ist als mein RAM und das System neugestartet. Genauso wie es in der 
Anleitung steht (sorry, link verschollen). Leider tut sich bei "Fn+F12" 
einfach nichts. Keine Ahnung was da schief gelaufen ist, es ist alles 
doppelt gecheckt und mehrmals probiert, es funzt einfach nicht. Aber das 
ist eine andere Geschichte...

>>> Ich hatte auch mal überlegt, xfs einzusetzen. Bin dann aber doch zu ext3
>>> gegangen, da ich für xfs damals keine Howtos gefunden habe, wie man
>>> gelöschte Dateien wiederherstellen kann. (Jaja, ein rm an der falschen
>>> Stelle, am besten noch mit -rf garniert...) Mit debugfs fahre ich da
>>> unter ext2/3 ganz gut. Aber möglicherweise gibt es vergleichbare Tools
>>> (und Howtos) mittlerweile auch für andere fs.
>>>       
>> Hmmm... das stürzt mich nicht in tiefe persönliche Abgründe, aber es 
>> irritiert etwas. Wenn man bei Google eingibt "gelöschte Datei 
>> wiederherstellen ext3" (oder so), steht überall drin, dass man von ext3 
>> keine Daten wiederherstellen kann...
>>     
>
> Danach habe ich jetzt nicht gesucht, um zu verstehen, was du meinst.
> Natürlich, wenn die Daten erstmal physikalisch auf der Platte (zum Teil)
> überschrieben sind, geht's nicht mehr. Aber ein `dump <inode-number>
> outfile' z. B. geht ganz gut unter debugfs, am besten, solange noch keine
> neuen Daten auf die Platte geschrieben wurden. Die Inode-Nummer kann man
> evt. aus der Ausgabe von `lsdel' (debugfs). Und in der Hilfe von debugfs
> sehe ich, es hat sogar ein eingebautes `undel', aber ich schreibe lieber
> nicht auf ein fs, das gemountet ist. Dann lieber per `dump' die
> Dateierzeugung dem Kernel überlassen.
>   
Ist ja schön, dass es doch eine Möglichkeit gibt im Ernstfall vielleicht 
noch an die verlorenen Daten zu kommen. Komisch, dass Google dazu nichts 
ausgespuckt hatte, aber wenn man nach debugfs sucht kriegt man schon die 
richtigen Ergebnisse.

Cool, wieder was gelernt!

Grüße,
Frank