nicht angemeldet
Auge
Der Martin
Der Martin
Der Martin
Jonathan
Der Martin
Der Martin
Hallo zusammen,
Ich habe gehört, das unter Linux keine Defragmentierung nötig sei. Stimmt das, oder ist das unfug.
Viele Grüsse gary
Hallo gary,
Ich habe gehört, das unter Linux keine Defragmentierung nötig sei. Stimmt das, oder ist das unfug.
Linux nutzt bestimmte Methoden, um Fragmentierung von Dateien zu verhindern, daher ist ein Defragmentieren in dem Fall nicht wirklich nötig.
Das Problem dabei ist: Damit das zuverlässig funktioniert, muss eine Mindestmenge an freien Speicher auf der Partition vorhanden sein (ich habe mal 15% gelesen, aber ich kann die Zahl aktuell nicht belegen). Wenn dies nicht der Fall ist, greift auch Linux zum Fragmentieren zurück (weil es sonst ja die Datei gar nicht speichern könnte, was noch schlecht wäre ;-)).
Übrigens: Auch neuere Windows-Versionen machen das gleiche, das betrifft also nicht nur Linux (wobei es Leute gibt, die behaupten, dass Windows das sehr viel schlechter beherrscht, als Linux; da ich mich nicht intensiv mit dem Thema auseinander gesetzt habe, kann ich aber selbst nichts dazu sagen). Und unabhängig vom Betriebssystem ist FAT als Dateisystem auf Grund der internen Datenstrukturen besonders schlecht für so etwas geeignet, daher sollte man FAT wenn möglich vermeiden.
Zudem ist zu beachten, dass Fragmentierung den größen von Puffern und Speicher-Caches heutzutage ein viel geringeres Problem darstellt, als zum Beispiel noch zu DOS/Windows 95-Zeiten.
Wobei Du unter Linux sowieso keine Möglichkeit hast, Dein Dateisystem zu defragmentieren. Das einzige mir bekannte Tool, das so etwas durchführt, nennt sich 'e2defrag' für ext2-Dateisysteme und mein Wissensstand ist, dass das Teil immer noch nicht als stabil gilt, d.h. ich würde es nicht einsetzen wollen, wenn mir meine Daten lieb sind.
Solltest Du also ein fragmentiertes Linux-Dateisystem vor Dir haben, ist die einzige Möglichkeit, es zu defragmentieren, indem Du alle Dateien woanders hin kopierst, das Dateisystem neu anlegst, und die Dateien zurückkopierst.
Viele Grüße,
Christian
Hallo Christian,
Linux nutzt bestimmte Methoden, um Fragmentierung von Dateien zu verhindern, daher ist ein Defragmentieren in dem Fall nicht wirklich nötig.
Aha.
Das Problem dabei ist: Damit das zuverlässig funktioniert, muss eine Mindestmenge an freien Speicher auf der Partition vorhanden sein (ich habe mal 15% gelesen
Das ist auch unter Windows so. Ist zu wenig Speicher übrig, streikt das Defragmentierungsprogramm.
Und unabhängig vom Betriebssystem ist FAT als Dateisystem auf Grund der internen Datenstrukturen besonders schlecht für so etwas geeignet, daher sollte man FAT wenn möglich vermeiden.
Ich halte nicht viel vom Fat16 oder Fat32 System. Wenn ich die Wahl habe nehme ich NTFS und bin damit immer gut gefahren. Vor allem ein Defrag läuft unter NTFS erheblich schneller.
Zudem ist zu beachten, dass Fragmentierung den größen von Puffern und Speicher-Caches heutzutage ein viel geringeres Problem darstellt, als zum Beispiel noch zu DOS/Windows 95-Zeiten.
Das verstehe ich nicht ganz. Wenn Magnetpunkte die eigentlich zu einem ganzen Datensatz (Datei) gehöhren , über die Festplattenscheibe verstreut angeordnet sind, dann ändert doch auch ein Puffer nichts daran, dass die "Scheibe" sich öfters drehen und der Lese/Schreibarm seine Position öfters ändern muss. Höchstens man hat die Indizierung am Laufen, die einen Gewissen Bereich vor und hinter aktuellen Zugriffen ausliest. Ich habe die Indizierung bei meinen Rechnern aber ausgeschaltet.
Wobei Du unter Linux sowieso keine Möglichkeit hast, Dein Dateisystem zu defragmentieren.
Oha, das wäre dann eher ein Grund gegen Linux. Kein zuverlässiges Notarztprogramm?
Solltest Du also ein fragmentiertes Linux-Dateisystem vor Dir haben, ist die einzige Möglichkeit, es zu defragmentieren, indem Du alle Dateien woanders hin kopierst, das Dateisystem neu anlegst, und die Dateien zurückkopierst.
Klingt auch nicht gerade wie das Gelbe vom Ei...
Ich habe das im Netz gefunden:
Sind das Systeme, aus denen ich wählen kann worauf ich Linux instaliere (Ubunthu)? Oder Laufen verschiedene Systeme gleichzeitig unter Linux.
Was ich auch noch gelesen habe: Unter Linux kann man mehrere Platten (HDD) als einzelnes Laufwerk einrichten. Also ist eine HDD fast voll, hängt man einfach ne neue dazu. Das stell ich mi praktisch vor.
So das war jetzt etwas viel auf einmal ;-)
Grüsse gary
Das Problem dabei ist: Damit das zuverlässig funktioniert, muss eine Mindestmenge an freien Speicher auf der Partition vorhanden sein (ich habe mal 15% gelesen
Das ist auch unter Windows so. Ist zu wenig Speicher übrig, streikt das Defragmentierungsprogramm.
Es ging aber gar nicht, um ein Defragmentierungsprogramm. Christian hat davon gesprochen, dass das Dateisystem (solange mindestens 15% des Speicherplatzes unbelegt sind) gar nicht erst anfängt stark zu fragmentieren.
Zudem ist zu beachten, dass Fragmentierung den größen von Puffern und Speicher-Caches heutzutage ein viel geringeres Problem darstellt, als zum Beispiel noch zu DOS/Windows 95-Zeiten.
Das verstehe ich nicht ganz. Wenn Magnetpunkte die eigentlich zu einem ganzen Datensatz (Datei) gehöhren , über die Festplattenscheibe verstreut angeordnet sind, dann ändert doch auch ein Puffer nichts daran, dass die "Scheibe" sich öfters drehen und der Lese/Schreibarm seine Position öfters ändern muss.
Nein, du solltest dich mit diesem Thema vielleicht nocheinmal beschäftigen. Mit dem Cache war nicht der Cache (statt RAM) auf der Festplatte selbst gemeint, sondern ein festplatteninterner Cache. Daten werden nicht sofort auf die Platze gekritzelt sondern erst gecached. Es sammeln sich also mehrere Daten im Cache, sodass diese aufeinmal und hintereinander geschrieben werden können und nicht auf der ganzen Platte verteilt werden.
Wobei Du unter Linux sowieso keine Möglichkeit hast, Dein Dateisystem zu defragmentieren.
Oha, das wäre dann eher ein Grund gegen Linux. Kein zuverlässiges Notarztprogramm?
Wenn ein Haus kein Feuer fängt und deshalb keine Feuerwehr in der Nähe ist, dann ist das ein Grund gegen das Haus? Verstehe ich nicht.
Solltest Du also ein fragmentiertes Linux-Dateisystem vor Dir haben, ist die einzige Möglichkeit, es zu defragmentieren, indem Du alle Dateien woanders hin kopierst, das Dateisystem neu anlegst, und die Dateien zurückkopierst.
Klingt auch nicht gerade wie das Gelbe vom Ei...
Ist bei Windows genau das gleiche.
Generell fragmentiert jedes Dateisystem immer, das geht nunmal nicht anders. Ein bisschen ist das sogar erwünscht, weil sich Dateien durchaus verändern und mal größer werden. Man reserviert z.B. unter Linux immer ein paar mehr Cluster hintereinander für eine Datei, falls diese später noch größer werden sollte.
Ich habe das im Netz gefunden:
ext2, ext3 linux
JFS, Journaled Files System, AIX
UFS, Unix File System, SUN
CDRFS, CDROM File System
NFS, Network File System, ursprünglich SUN
DFS, Distributed File System, viele Hersteller
SAMBA, SMB-Fileserver, NTFS (NT, Windows/2000),
Gibt noch einige mehr.
Sind das Systeme, aus denen ich wählen kann worauf ich Linux instaliere (Ubunthu)? Oder Laufen verschiedene Systeme gleichzeitig unter Linux.
Beschäftige dich nochmal mit dem ganzen Thema, bitte. Halbwissen ist manchmal gefährlich.
Hallo Derda,
Es ging aber gar nicht, um ein Defragmentierungsprogramm. Christian hat davon gesprochen, dass das Dateisystem (solange mindestens 15% des Speicherplatzes unbelegt sind) gar nicht erst anfängt stark zu fragmentieren.
Das habe ich verstanden. Ich wollte nur auf die 15% hinweisen, die für Windows Defrag gelten.
Nein, du solltest dich mit diesem Thema vielleicht nocheinmal beschäftigen. Mit dem Cache war nicht der Cache (statt RAM) auf der Festplatte selbst gemeint, sondern ein festplatteninterner Cache. Daten werden nicht sofort auf die Platze gekritzelt sondern erst gecached. Es sammeln sich also mehrere Daten im Cache, sodass diese aufeinmal und hintereinander geschrieben werden können und nicht auf der ganzen Platte verteilt werden.
Gut, jetzt weiss ich was mit Puffer gemeint war. Trotzdem lässt es sich wohl nicht vermeiden, eine Datei öfter zu öffnen und zu schliessen. Auch bei unterschiedlichen Sitzungen. Das kann auch der beste Cache nicht verhindern.
Und wenn die Daten dann auf unterschiedlichen Tracks und Sektoren liegen, erhöht sich halt die Zugriffszeit.
Wenn ein Haus kein Feuer fängt und deshalb keine Feuerwehr in der Nähe ist, dann ist das ein Grund gegen das Haus? Verstehe ich nicht.
...gar nicht erst anfängt _stark_ zu fragmentieren...
Heisst doch, dass es dennoch fragmentiert (sagen wir, dass Haus ist schwer entflammbar *g*). Da wäre doch ein Programm gut, das die Neuanlage des Dateisystems und der Daten automatisiert.
Beschäftige dich nochmal mit dem ganzen Thema, bitte. Halbwissen ist manchmal gefährlich.
Ich beschäftige mich ja mit dem Thema - wobei man das auch anders formulieren kann *hehe*
z.B. das da:
Will man wissen, welchen Typ die Dateisysteme haben, so hilft mount:
/dev/sdb6 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/sda1 on /boot type ext2 (rw)
/dev/sda5 on /home type ext2 (rw)
/dev/sdb1 on /usr type ext2 (rw)
/dev/sdb5 on /var type ext2 (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
Da steht doch schwarz auf weis "ext2" und drunter "proc" und drunter "devpts". Das heisst doch verschiedene Filesysteme. Ich frage desshalb, weil ich nur Windows kenne, und dort in der Regel n ur _ein_ Dateisystem anzutreffen ist.
Viele Grüsse gary
Hallo gary,
Da steht doch schwarz auf weis "ext2" und drunter "proc" und drunter "devpts". Das heisst doch verschiedene Filesysteme. Ich frage desshalb, weil ich nur Windows kenne, und dort in der Regel n ur _ein_ Dateisystem anzutreffen ist.
Linux (und POSIX allgemein) verwendet oftmals das Dateisystem, um bestimmte Kernel-Informationen/-Funktionalitäten zur Verfügung zu stellen.
"proc" und "devpts" sind virtuelle Dateisystemtypen, die eine bestimmte Schnittstelle zum Kernel bieten. Im Verzeichnis /proc/1234 befinden sich zum Beispiel eine ganze Menge Informationen zum Prozess mit der Prozess-ID 1234. Bei beiden Dateisystemen in Deiner moun-Ausgabe siehst Du ja auch bereits, dass diese beiden Beispiele als Quelle "none" drinsteht, d.h. da kein physikalisches Gerät gemountet ist, sondern das ganze wirklich nur ein virtuelles Dateisystem darstellt.
Viele Grüße,
Christian
Wenn ein Haus kein Feuer fängt und deshalb keine Feuerwehr in der Nähe ist, dann ist das ein Grund gegen das Haus? Verstehe ich nicht.
...gar nicht erst anfängt _stark_ zu fragmentieren...Heisst doch, dass es dennoch fragmentiert (sagen wir, dass Haus ist schwer entflammbar *g*). Da wäre doch ein Programm gut, das die Neuanlage des Dateisystems und der Daten automatisiert.
Ja, diese Fragmentierung erhöht die Zugriffsgeschwindigkeit indirekt ;)
Warum das so ist, hat Christian Seiler dem Martin schon erklärt. (vierter Beitrag in diesem Thema)
Das habe ich verstanden. Ich wollte nur auf die 15% hinweisen, die für Windows Defrag gelten.
Diese 15% braucht das Defrag-Programm um die Daten umzuschaufeln, das hat mit den 15%, die frei bleiben sollen, um Fragmentierung zu verhindern, absolut gar nichts zu tun.
Hi Multi,
Das habe ich verstanden. Ich wollte nur auf die 15% hinweisen, die für Windows Defrag gelten.
Diese 15% braucht das Defrag-Programm um die Daten umzuschaufeln, das hat mit den 15%, die frei bleiben sollen, um Fragmentierung zu verhindern, absolut gar nichts zu tun.
Das weis ich doch. Ich habe es nur erwähnt, weil die Zahl identisch ist.
Viele Grüsse gary
Hallo gary,
Das Problem dabei ist: Damit das zuverlässig funktioniert, muss eine Mindestmenge an freien Speicher auf der Partition vorhanden sein (ich habe mal 15% gelesen
Das ist auch unter Windows so. Ist zu wenig Speicher übrig, streikt das Defragmentierungsprogramm.
Nein, mir ging's nicht ums Defragmentierungsprogramm, sondern um den Kern selbst. Wenn (wie gesagt, über die Zahl bin ich mir nicht ganz sicher) soundsoviel Prozent des Speichers noch frei sind, dann fängt Linux gar nicht an, merklich zu fragmentieren, d.h. nur wenn man Platten "bis zum Anschlag" befüllt hat man damit Probleme.
Zudem ist zu beachten, dass Fragmentierung den größen von Puffern und Speicher-Caches heutzutage ein viel geringeres Problem darstellt, als zum Beispiel noch zu DOS/Windows 95-Zeiten.
Das verstehe ich nicht ganz. Wenn Magnetpunkte die eigentlich zu einem ganzen Datensatz (Datei) gehöhren , über die Festplattenscheibe verstreut angeordnet sind, dann ändert doch auch ein Puffer nichts daran, dass die "Scheibe" sich öfters drehen und der Lese/Schreibarm seine Position öfters ändern muss.
Ja, beim ersten Auslesen, d.h. beim Hochfahren des Systems. Aber wenn Du eine Datei häufig brauchst, dann muss diese heutzutage gar nicht mehr von der Festplatte gelesen werden (genügend RAM vorausgesetzt), sondern bleibt im Speicher. Dann ist es relativ egal, wie stark die Festplatte fragmentiert.
Zudem: Beim Schreiben einer Datei kann im RAM erstmal gesammelt werden, bevor sie geschrieben wird. Damit kann unter Umständen vorher erkannt werden, wie groß eine Datei in etwa werden soll - zumindest bei kleinen Blockgrößen. Fragmentierung ist ja sowieso nur dann interessant, wenn vor allem in sehr kleine Brocken aufgeteilt wird. Wenn Du eine 4 GiB große Datei hast (z.B. einen großen Film) und der ist in 5 oder 6 große Brocken aufgeteilt, dann fällt das gar nicht auf. Wenn Du aber Dateien der Größenordnung 100 KiB in 5 oder 6 Brocken aufteilst, _dann_ merkst Du es. Und wenn der Kernel zumindest dafür sorgen kann, dass die Fragmente eine Mindestgröße haben, dann fällt das lange nicht so ins Gewicht.
Wobei Du unter Linux sowieso keine Möglichkeit hast, Dein Dateisystem zu defragmentieren.
Oha, das wäre dann eher ein Grund gegen Linux. Kein zuverlässiges Notarztprogramm?
Wieso Notarzt? Ein fragmentiertes Dateisystem funktioniert doch auch noch genauso, da muss man nichts reparieren. Ein "Notarztprogramm" wäre ein Programm, das ein beschädigtes Dateisystem repariert - und die gibt es, funktionieren auch zuverlässig.
Und wie gesagt: Wenn Du die Platte nicht randvoll machst, brauchts Du unter Linux kein Defragmentierungsprogramm (kann ich aus eigener Erfahrung auch bestätigen), unter neueren Windows angeblich auch nicht.
Ich habe das im Netz gefunden:
ext2, ext3 linux
JFS, Journaled Files System, AIX
UFS, Unix File System, SUN
CDRFS, CDROM File System
NFS, Network File System, ursprünglich SUN
DFS, Distributed File System, viele Hersteller
SAMBA, SMB-Fileserver, NTFS (NT, Windows/2000),
Sind das Systeme, aus denen ich wählen kann worauf ich Linux instaliere (Ubunthu)? Oder Laufen verschiedene Systeme gleichzeitig unter Linux.
Oh, da wirfst Du aber EINIGES durcheinander. Zuerst einmal gibt es physikalische Dateisysteme, die Du tatsächlich auf ein Medium packst. Dazu zählen FAT, NTFS, ext2, ext3, ReiserFS, JFS, XFS, ISO96660, UDF, UFS, HFS, HFS+ und noch viele mehr. Dann gibt es Netzwerkdateisysteme, d.h. Möglichkeiten, Dateien über das Netzwerk anzusprechen. Unter Linux wird dies über einen Dateisystemtreiber realisiert (daher NFS, AFS, NCPFS, smbfs, CIFS, ...), unter Windows funktioniert das etwas anders.
Linux kann man auf eine ganze Menge von Dateisystemen installieren. Einige davon bieten sogenanntes "Journaling", was im Endeffekt eine erhöhte Sicherheit bedeutet, wenn der Server mal crasht (vor allem muss dann das Dateisystem nicht komplett geprüft werden beim nächsten Hochfahren, es reicht, wenn nur bestimmte Teile analysiert werden, was enorm Zeit spart).
Linux installiert man heutzutage typischerweise auf entweder ext2, ext3, ReiserFS, XFS oder JFS. Andere Dateisysteme sind möglich, allerdings nicht gebräuchlich. ext3, ReiserFS, XFS und JFS können alle Journaling; ext3 ist kompatibel zu ext2 (lies: ein intaktes ext3-Dateisystem kann man auch mit einem ext2-Treiber ansprechen, halt nur ohne Journaling) und bietet eigentlich "nur" Journaling als Extra-Feature.
Ferner gibt es unter Linux noch Treiber für andere Dateisysteme wie NTFS, FAT, UFS oder auch Netzwerkdateisysteme wie NFS. Einige dieser Dateisysteme können nur gelesen werden oder es wird nur rudimentäre Schreibunterstützung geboten (zum Beispiel bei NTFS).
Was ich auch noch gelesen habe: Unter Linux kann man mehrere Platten (HDD) als einzelnes Laufwerk einrichten. Also ist eine HDD fast voll, hängt man einfach ne neue dazu. Das stell ich mi praktisch vor.
Das geht (Stichwort "linear md"), allerdings hat das den großen Nachteil, dass wenn eine Platte ausfällt, potentiell eine Menge Daten verloren sind (und nachdem Dateisysteme idR. nicht auf so einen Betrieb ausgelegt sind, dürfte das wiederherstellen selbst nur eines Teils der Daten schwierig werden). Zwar immer noch besser als RAID-0 oder striping md, bei dem alle Daten weg sind, aber nicht wirklich empfehlenswert. Zudem: Das Dateisystem muss dann trotzdem vergrößert werden, auch wenn Du die Platte anhängst - DAS geht mit den meisten Linux-Dateisystemen allerdings auch im laufenden Betrieb.
Viele Grüße,
Christian
Hallo Christian,
Ihr seit ja alle nicht ganz frisch *ganz-breites-smile*
Sag mal hab ihr das "Zeugs" studiert oder was? (linear md / raid 0 / HDD im laufendem Betrieb wechseln *häää?* - man wechselt ja auch nicht das Lenkrad während der Fahrt *hehehe*)
Nene, schon gut. Ich denke ext2 oder ext3 ist mindestens so gut wie NTFS. Hauptsache kein FAT32...
Viele Dank für die vielen kompetenten Antworten
Gruss gary
man wechselt ja auch nicht das Lenkrad während der Fahrt *hehehe*)
Wenn ein Lenkrad wärend der Fahrt ausfällt, hast du auch ganz andere Probleme. Wenn eine Festplatte ausfällt und der Server für 5 Minuten steht um ne Platte zu tauschen, kann das im Extremfall Millionen kosten oder sogar Menschenleben.
Aus dem Grund müss es möglich sein, Festplatten im laufenden Betrieb zu wechseln.
Hallo
Wenn eine Festplatte ausfällt und der Server für 5 Minuten steht um ne Platte zu tauschen, kann das im Extremfall Millionen kosten oder sogar Menschenleben.
Aus dem Grund müss es möglich sein, Festplatten im laufenden Betrieb zu wechseln.
Wobei gerade das erwähnte RAID0 ein denkbar schlechtes -genauer gesagt "unpassendes"- Beispiel dafür ist, zumal es nichtmal seinem Namen (redundant ...) gerecht wird.
Tschö, Auge
Wobei gerade das erwähnte RAID0 ein denkbar schlechtes -genauer gesagt "unpassendes"- Beispiel dafür ist, zumal es nichtmal seinem Namen (redundant ...) gerecht wird.
Da hast du natürlich Recht. Da wäre ein Raid1 nötig, oder evtl. ein Raid5. Welches Raid das optimale ist, ist abhängig vom Anwendungsfall.
Moin!
Zudem ist zu beachten, dass Fragmentierung den größen von Puffern und Speicher-Caches heutzutage ein viel geringeres Problem darstellt, als zum Beispiel noch zu DOS/Windows 95-Zeiten.
Das verstehe ich nicht ganz. Wenn Magnetpunkte die eigentlich zu einem ganzen Datensatz (Datei) gehöhren , über die Festplattenscheibe verstreut angeordnet sind, dann ändert doch auch ein Puffer nichts daran, dass die "Scheibe" sich öfters drehen und der Lese/Schreibarm seine Position öfters ändern muss. Höchstens man hat die Indizierung am Laufen, die einen Gewissen Bereich vor und hinter aktuellen Zugriffen ausliest. Ich habe die Indizierung bei meinen Rechnern aber ausgeschaltet.
Defragmentierung von Festplatten ist im Prinzip Augenwischerei und Verschwendung von CPU-Zyklen. :)
Es ist Aufgabe der Festplatte, einen angeforderten Datenbereich schnellstmöglich zu lesen und zu liefern.
Defragmentierung von Dateien beschleunigt das aber nur bedingt, denn in Multi-Tasking-Systemen wird ja nie seriell nur eine Datei zur Zeit angefordert, sondern in der Regel parallel mehrere (von Zugriffen auf den Auslagerungsbereich des virtuellen Speichers mal ganz zu schweigen.
Das bedeutet, dass das Zugriffsmuster auf die Datenbereiche ohnehin ziemlich verstreut ist - egal ob dabei nun eine Datei schön am Stück oder eben fragmentiert lagert. Man kann auch mit komplett unfragmentierten Dateien ein Worst-Case-Szenario bilden, in dem die Zugriffsgeschwindigkeit minimal wird. Und genauso kann man für dieses Zugriffsmuster wiederum die optimale Datenanordnung auf der Festplatte herstellen, indem man "Defragmentiert" - in diesem Fall also eher fragmentiert, indem die Dateiblöcke passend wie angefordert hintereinandergelagert würden.
Wobei Du unter Linux sowieso keine Möglichkeit hast, Dein Dateisystem zu defragmentieren.
Oha, das wäre dann eher ein Grund gegen Linux. Kein zuverlässiges Notarztprogramm?
Defragmentierung ist ein Festplattenoptimierungsversuch aus DOS-Zeiten, bedingt durch das schlechte Fragmentierungsverhalten des FAT-Dateisystems.
Wieso muß Linux sowas auch bieten, wenn es von vorne herein besser ist? :)
Gerade unter Linux, dass von Anfang an ein Multiuser- und Multitasking-Betriebssystem war, wurden die besonderen Anforderungen dieses Szenarios mit einbezogen - nicht so wie bei Windows, wo man aus Kompatibilitätsgründen dem DOS erst ein GUI überstülpte, dass dann plötzlich Multitasking machte.
Ich habe das im Netz gefunden:
ext2, ext3 linux
JFS, Journaled Files System, AIX
UFS, Unix File System, SUN
CDRFS, CDROM File System
NFS, Network File System, ursprünglich SUN
DFS, Distributed File System, viele Hersteller
SAMBA, SMB-Fileserver, NTFS (NT, Windows/2000),
Sind das Systeme, aus denen ich wählen kann worauf ich Linux instaliere (Ubunthu)? Oder Laufen verschiedene Systeme gleichzeitig unter Linux.
Linux nutzt problemlos alle möglichen Dateisysteme parallel. Windows nutzt ja auch NTFS und FAT32, FAT16 und FAT12 parallel. :)
Was ich auch noch gelesen habe: Unter Linux kann man mehrere Platten (HDD) als einzelnes Laufwerk einrichten. Also ist eine HDD fast voll, hängt man einfach ne neue dazu. Das stell ich mi praktisch vor.
Wenn es um problemlose Erweiterbarkeit von Festplattenplatz geht, ist für Linux LVM2 empfehlenswert.
Aber auch Windows ab 2000 kann neue Partitionen nicht nur als neuen Laufwerksbuchstaben einbinden, sondern an beliebigen Orten im Dateisystem. Man kann sich also (sicher mit ein wenig Umkopierarbeit) auch auf bereits gut gefüllten Partitionen in Unterverzeichnissen neuen Platz schaffen, ohne die Verzeichnisstruktur komplett umbauen zu müssen.
- Sven Rautenberg
Defragmentierung von Festplatten ist im Prinzip Augenwischerei und Verschwendung von CPU-Zyklen. :)
Aha.
Es ist Aufgabe der Festplatte, einen angeforderten Datenbereich schnellstmöglich zu lesen und zu liefern.
Aha. Aber du verweigerst der Festplatte die volle Leistung, indem du ihr zumutest, bei einer Datei den Schreib/Lesekopf zigfach bewegen muss.
Defragmentierung von Dateien beschleunigt das aber nur bedingt, denn in Multi-Tasking-Systemen wird ja nie seriell nur eine Datei zur Zeit angefordert, sondern in der Regel parallel mehrere (von Zugriffen auf den Auslagerungsbereich des virtuellen Speichers mal ganz zu schweigen.
Also wenn du kochen willst, den Topf aus dem Wohnzimmer, den Kochlöffel aus dem Keller und die Nubeln aus dem Schlafzimmer holen musst, bist du genauso schnell, als wenn alles in der Küche wäre?
Gerade bei vielen geöffneten Dateien ist es entscheidend, ob diese fragmentiert sind, da sich die nötige Bewegung des Schreib/Lesekopfes multipliziert und nicht auf eine einzelne Datei begrenzt ist.
Selbst das Füllen des Cache wird durch eine Fragmentierung verlangsamt und bremst somit das komplette System.
Moin!
Es ist Aufgabe der Festplatte, einen angeforderten Datenbereich schnellstmöglich zu lesen und zu liefern.
Aha. Aber du verweigerst der Festplatte die volle Leistung, indem du ihr zumutest, bei einer Datei den Schreib/Lesekopf zigfach bewegen muss.
Es muß ja einen Grund haben, warum die aktuelle Optimierungsbemühung bei Festplatten mit Native Command Queuing eben gerade den Ansatz wählt, die unweigerlich auftretenden Seeks auf der Festplatte vom Weg her zu optimieren.
Es reicht doch schon, wenn du eine größere Datei einlesen willst, und parallel dazu das OS Swapping betreibt, weil die eingelesene Datei RAM-Speicher erfordert, der freigeschaufelt werden muß. Zack hast du einen rödelnden Plattenkopf, der zwischen zwei Partitionsbereichen hin- und herspringen muß. Da dürfte es ziemlich egal sein, ob die zu lesende Datei nun in einem Stück vorliegt, oder in fünf Fragmenten.
Defragmentierung von Dateien beschleunigt das aber nur bedingt, denn in Multi-Tasking-Systemen wird ja nie seriell nur eine Datei zur Zeit angefordert, sondern in der Regel parallel mehrere (von Zugriffen auf den Auslagerungsbereich des virtuellen Speichers mal ganz zu schweigen.
Also wenn du kochen willst, den Topf aus dem Wohnzimmer, den Kochlöffel aus dem Keller und die Nubeln aus dem Schlafzimmer holen musst, bist du genauso schnell, als wenn alles in der Küche wäre?
Kochen ist nicht Multitasking. Kochen, Wäschewachen und Staubsaugen wäre Multitasking - und dann komme ich, weil ich staubsaugen will, in Wohnzimmer und Schlafzummer vorbei und schnapp mir den Kochlöffel und die Nudeln, und aus der Waschküche im Keller bringe ich den Topf mit.
Gerade bei vielen geöffneten Dateien ist es entscheidend, ob diese fragmentiert sind, da sich die nötige Bewegung des Schreib/Lesekopfes multipliziert und nicht auf eine einzelne Datei begrenzt ist.
Die Anzahl der geöffneten Dateien ist vollkommen irrelevant, eine Datei offen zu haben transferiert keine nennenswerten Daten - mit Ausnahme des Lesens des Directoryeintrags.
Selbst das Füllen des Cache wird durch eine Fragmentierung verlangsamt und bremst somit das komplette System.
Caches sind ein Thema für sich. Ein übliches Computersystem hat davon ganz viele unterschiedliche, die alle irgendeinen Einfluß nehmen - und das wird sicherlich in den seltensten Fällen negative Auswirkungen haben.
- Sven Rautenberg
Kochen ist nicht Multitasking.
Und der Zugriff in einer Festplatte mit _einem_ Schreiblesearm auch nicht. Denn dabei müssten die zu lesenden Cluster an exakt der gleichen Stelle stehen, nur auf einer anderen Scheibe. Sonst ist ein paralleles Auslesen von Clustern nicht möglich.
Hallo Christian,
Linux nutzt bestimmte Methoden, um Fragmentierung von Dateien zu verhindern, ...
ich verstehe das so, dass die üblichen Linux-Dateisysteme eine Datei, wenn immer möglich, am Stück speichern, anstatt sie in mehrere Fragmente zu splitten.
Das tut Windows mit NTFS und FAT32 aber auch, wie du ja selbst einräumst:
Übrigens: Auch neuere Windows-Versionen machen das gleiche, das betrifft also nicht nur Linux (wobei es Leute gibt, die behaupten, dass Windows das sehr viel schlechter beherrscht, als Linux; da ich mich nicht intensiv mit dem Thema auseinander gesetzt habe, kann ich aber selbst nichts dazu sagen).
Was dabei gern übersehen wird: Nicht nur Dateien können fragmentiert gespeichert sein - auch der noch freie Platz auf der Platte wird nach und nach fragmentiert.
Und unabhängig vom Betriebssystem ist FAT als Dateisystem auf Grund der internen Datenstrukturen besonders schlecht für so etwas geeignet, daher sollte man FAT wenn möglich vermeiden.
Diese Aussage überrascht mich. Gut, ich weiß nicht, wie z.B. ext2/ext3 funktionieren. Aber bei FAT12/16/32 sind alle Verwaltungsstrukturen am Anfang des Datenträgers wohlgeordnet zusammengefasst, während NTFS auch seine eigenen Strukturen (Master File Tables) quer über die ganze Partition verstreut. Die werden übrigens auch bei einer Defragmentierung nie wieder angefasst, so dass ein NTFS-Volume nach einiger Zeit viel "unordentlicher" aussieht als ein FAT-Laufwerk.
Wobei Du unter Linux sowieso keine Möglichkeit hast, Dein Dateisystem zu defragmentieren.
Unter NTFS auch nicht wirklich; unter FAT geht's etwas besser, aber auch unbefriedigend. Das Windows-Tool ist eigentlich nur Augenwischerei. Es reorganisiert keine NTFS File Tables, es defragmentiert in der Defaulteinstellung keine Systemdateien, geschweige denn die Aulagerungsdatei, es defragmentiert keine Verzeichnisse.
Solltest Du also ein fragmentiertes Linux-Dateisystem vor Dir haben, ist die einzige Möglichkeit, es zu defragmentieren, indem Du alle Dateien woanders hin kopierst, das Dateisystem neu anlegst, und die Dateien zurückkopierst.
Das ist auch bei Windows-Dateisystemen die sauberste Lösung.
Schönes Wochenende noch,
Martin
Hallo Martin,
Linux nutzt bestimmte Methoden, um Fragmentierung von Dateien zu verhindern, ...
ich verstehe das so, dass die üblichen Linux-Dateisysteme eine Datei, wenn immer möglich, am Stück speichern, anstatt sie in mehrere Fragmente zu splitten.
Ja. Vereinfacht gesagt funktioniert das so: Der Kernel reserviert für eine Datei beim Anlegen gleich mal deutlich mehr Speicher auf der Festplatte und erst wenn er feststellt "oh, die Datei ist jetzt doch kleiner", gibt er diese wieder frei.
Und unabhängig vom Betriebssystem ist FAT als Dateisystem auf Grund der internen Datenstrukturen besonders schlecht für so etwas geeignet, daher sollte man FAT wenn möglich vermeiden.
Diese Aussage überrascht mich.
Ich habe vor längerer Zeit irgendwo gelesen, dass Linux auf einem FAT-Dateisystem noch stärker fragmentiert, als auf nativen Dateisystemen. Das kann man sich ja eigentlich nur so erklären.
Ich bin kein Experte auf dem Gebiet, daher kann ich Dir daher leider nichts genaueres dazu sagen.
Unter NTFS auch nicht wirklich; unter FAT geht's etwas besser, aber auch unbefriedigend. Das Windows-Tool ist eigentlich nur Augenwischerei.
*hehe* Das erklärt auch, warum das bei mir nie wirklich etwas gebracht hat, daher habe ich's unter Windows irgendwann auch gelassen, zu defragmentieren.
Viele Grüße,
Christian
Wobei Du unter Linux sowieso keine Möglichkeit hast, Dein Dateisystem zu defragmentieren.
Das ist so nicht ganz richtig.
Eine 100%ige Defragmentierung ist dadurch zu erreichen, per dd ein Image zu erzeugen, die komplette Platte zu löschen und das Image zurückzuspielen.
Zugegeben, kein überaus pratikabler Weg, aber machbar ist es.
Hallo,
Eine 100%ige Defragmentierung ist dadurch zu erreichen, per dd ein Image zu erzeugen, die komplette Platte zu löschen und das Image zurückzuspielen.
wenn du ein Image zurückspielst, hast du wieder ein exaktes Abbild aller vorherigen Strukturen. Einschließlich der vorher herrschenden Unordnung und eventueller Dateisystemfehler.
Zugegeben, kein überaus pratikabler Weg, aber machbar ist es.
Ja. Aber es bringt dich keinen Schritt weiter.
So long,
Martin
wenn du ein Image zurückspielst, hast du wieder ein exaktes Abbild aller vorherigen Strukturen. Einschließlich der vorher herrschenden Unordnung und eventueller Dateisystemfehler.
Wenn ich das Image per dd erzeugt, nicht. Dieses Image ist Dateibasiert und nicht Clusterbasiert. Wenn ich mich nicht täusche, arbeiten Norton Ghost u.a. auch in dieser Art.
Ja. Aber es bringt dich keinen Schritt weiter.
Aber sicher doch. Und wenn ein Image ein 1zu1-Clusterabblid ist, geb ich dir Recht, allerdings kenne ich mehr Image-Arten, die das eben _nicht_ sind.
Hallo,
wenn du ein Image zurückspielst, hast du wieder ein exaktes Abbild aller vorherigen Strukturen. Einschließlich der vorher herrschenden Unordnung und eventueller Dateisystemfehler.
Wenn ich das Image per dd erzeugt, nicht. Dieses Image ist Dateibasiert und nicht Clusterbasiert.
das ist ein Irrtum. Mit dd erzeugst du ein bitgetreues Abbild der Quelldatei oder des Datenträgers bzw. der Partition.
Und wenn ein Image ein 1zu1-Clusterabblid ist, geb ich dir Recht, allerdings kenne ich mehr Image-Arten, die das eben _nicht_ sind.
Dann dürften sie nicht "image" (Abbild) nennen. Unter einem Image verstehe ich eine Technik, mit der ich ein bitgetreues Abbild erzeugen kann.
Ciao,
Martin
das ist ein Irrtum. Mit dd erzeugst du ein bitgetreues Abbild der Quelldatei oder des Datenträgers bzw. der Partition.
Aha. Und wenn ich jetzt alle Dateien in dieses Image kopiere, sind die Daten immer noch fragmentiert? Ich hab nie behauptet, du sollst die Festplatte auf Clusterebene kopieren, sondern du sollst den Platteninhalt per dd kopieren.
Dann dürften sie nicht "image" (Abbild) nennen. Unter einem Image verstehe ich eine Technik, mit der ich ein bitgetreues Abbild erzeugen kann.
Willst du mir jetzt erzählen, das ein iso9660-Image fragmentierte Daten enthält? Oder ist ein Iso-Image kein Image?
Hallo Multi,
Aha. Und wenn ich jetzt alle Dateien in dieses Image kopiere, sind die Daten immer noch fragmentiert? Ich hab nie behauptet, du sollst die Festplatte auf Clusterebene kopieren, sondern du sollst den Platteninhalt per dd kopieren.
Ich kenne das auch nur zum binären Abbild erstellen, also z.B.
dd -if /dev/sda1 -of ~/image
Wenn ich das mit (mehreren) Dateien machen würde, hätte ich Angst, dass die ohen Dateisystem einfach aneinandergeklatscht würden.
Willst du mir jetzt erzählen, das ein iso9660-Image fragmentierte Daten enthält? Oder ist ein Iso-Image kein Image?
Was hat denn ein iso-Image mit einem Linux-Dateisystem zu tun? Ob CD-Dateisysteme überhaupt fragmentieren können, halte ich ja schon für recht fraglich.
Oder willst ein Dateisystem defragmentieren, indem du es ins iso9660-Format umwandelst? Das wäre ja mega-schwachsinnig, wenn man mal von einfachsten Fall, nämlich einem CD-Backup absieht.
Jonathan
Hallo
Willst du mir jetzt erzählen, das ein iso9660-Image fragmentierte Daten enthält? Oder ist ein Iso-Image kein Image?
Was hat denn ein iso-Image mit einem Linux-Dateisystem zu tun?
Was hat das mit der Fragestellung zu tun? Die Frage war, ob ein Image der Daten einer Platte, Partition, wasauchimmer, deren auf dem ursprünglichen Datenträger bestehende Fragmentierung übernimmt.
Tschö, Auge
Hallo Auge,
Was hat das mit der Fragestellung zu tun? Die Frage war, ob ein Image der Daten einer Platte, Partition, wasauchimmer, deren auf dem ursprünglichen Datenträger bestehende Fragmentierung übernimmt.
Und das hängt ganz einfach davon ab, was man als Image versteht bzw. wie man das image herstellt. Wenn ich aus ext3-Dateien ein iso9660-Image erstelle, erstelle ich ja eben keine binär-Kopie, deswegen ist es dann auch klar, dass das Resultat nicht fragmentiert sein wird. Aber das ist ja das gleiche, als wenn ich die Dateien auf eine fat-Partition kopiere.
Aber bei einem einem kopieren mit dd übernimmt man natürlich die Fragmentierung, und eben auch das Dateisystem. Mit dd von einer ext3-Partition ein iso9660-Image erstellen zu wollen halte ich für ziemlich idiotisch.
Jonathan
Aber das ist ja das gleiche, als wenn ich die Dateien auf eine fat-Partition kopiere.
Aha, auch du bist der Meinung, das ein Kopieren, welches nachweislich wieder fragmentiert, das Gleiche ist, wie das Erzeugen eines Images? Ich merke das tiefe Verständnis der Materie.
Aber bei einem einem kopieren mit dd übernimmt man natürlich die Fragmentierung, und eben auch das Dateisystem.
Nur, weil du es nicht besser kannst, können es aber vielleicht andere. Es soll Leute geben, die die gesammte Funktionalität eines Programmes begreifen und diese auch nutzen.
Mit dd von einer ext3-Partition ein iso9660-Image erstellen zu wollen halte ich für ziemlich idiotisch.
Wieso du dann als einziger diese Möglichkeit in den Raum stellt, erschliesst sich mir leider nicht.
Hallo Multi,
Aha, auch du bist der Meinung, das ein Kopieren, welches nachweislich wieder fragmentiert,
Wenn ich Dateien auf eine andere Partition kopiere fragmentiert da nichts, jedenfalls nicht, wenn die Partition vorher leer oder unfragmentiert war.
das Gleiche ist, wie das Erzeugen eines Images?
Nein, das hab ich nie behauptet.
Wieso du dann als einziger diese Möglichkeit in den Raum stellt, erschliesst sich mir leider nicht.
Ich stelle die Aussage nicht in den Raum, sondern habe versucht einen ziemlich merkwürdigen Satz aus einem vorhergehenden Post zu begreifen.
Jonathan
Hallo
Wieso du dann als einziger diese Möglichkeit in den Raum stellt, erschliesst sich mir leider nicht.
Ich stelle die Aussage nicht in den Raum, sondern habe versucht einen ziemlich merkwürdigen Satz aus einem vorhergehenden Post zu begreifen.
Die Frage war, ob es Images gibt, die die Fragmentierung des Originals _nicht_ übernehmen. Als Beispiel für die Nichtübernahme der Fragmentierung des Originals wurde das ISO-Image herangezogen und die Nachfrage gestellt, ob dies etwa kein Image sei. Was ist daran merkwürdig?
Tschö, Auge
Hallo Auge,
Die Frage war, ob es Images gibt, die die Fragmentierung des Originals _nicht_ übernehmen. Als Beispiel für die Nichtübernahme der Fragmentierung des Originals wurde das ISO-Image herangezogen und die Nachfrage gestellt, ob dies etwa kein Image sei. Was ist daran merkwürdig?
Das merkwürdige ist eben, dass ich in dem Fall eben kein Image des vorhandenen Dateisystems erstelle, sondern ein neues CD-Abbild erstelle und da die Dateien mehr oder weniger reinkopiere¹.
Schon allein die Frage ist merkwürdig. Von einem Dateisystem gibt es nur ein einziges mögliches Image². Und dieses eine Image übernimmt die eventuell vorhandene Fragmentierung natürlich und in jedem Fall.
¹) Ja, ich weiß das iso9660-Dateisysteme normalerweise readonly sind. Aber die Formulierung trifft noch ganz gut.
²) von irgendwelchen Eigenheiten/Komprimierungen eines Containerformats mal abgesehen
Jonathan
Ich kenne das auch nur zum binären Abbild erstellen, also z.B.
dd -if /dev/sda1 -of ~/image
Nur weil du nur diese Version kennst, heisst es nicht, das es die einzige ist ...
Wenn ich das mit (mehreren) Dateien machen würde, hätte ich Angst, dass die ohen Dateisystem einfach aneinandergeklatscht würden.
Wenn die Merkel bei mir im Schlafzimmer erscheinen würde, hätte ich angst, impotent zu werden. Und was hat das jetzt mit dem Thema zu tun?
Was hat denn ein iso-Image mit einem Linux-Dateisystem zu tun?
Was hat das mit dem Thema zu tun?
Ob CD-Dateisysteme überhaupt fragmentieren können, halte ich ja schon für recht fraglich.
Ist es nicht genau das, was ich gesagt habe, das es ebene _nicht_ fragmentiert?
Oder willst ein Dateisystem defragmentieren, indem du es ins iso9660-Format umwandelst? Das wäre ja mega-schwachsinnig, wenn man mal von einfachsten Fall, nämlich einem CD-Backup absieht.
Der einzige, der davon redet, bist du selbst. Wieso du sowas reininterpretierst, nur weil ich dieses Beispiel als _eines_von_vielen_ Imagearten angeführt hab, versteh ich nicht. Aber jeder liest das, was er lesen will.
Hallo Multi,
Nur weil du nur diese Version kennst, heisst es nicht, das es die einzige ist ...
Ich hab nichts anders gesagt und ehrlich gesagt eher darauf gehofft, tipps zu kriegen, was man noch für tolle Sachen mit dd machen kann, als dumme Sprüche zu kriegen.
Was hat denn ein iso-Image mit einem Linux-Dateisystem zu tun?
Was hat das mit dem Thema zu tun?
Genau das hab ich mich auch gefragt, bei folgenem Satz:
--
Dann dürften sie nicht "image" (Abbild) nennen. Unter einem Image verstehe ich eine Technik, mit der ich ein bitgetreues Abbild erzeugen kann.
Willst du mir jetzt erzählen, das ein iso9660-Image fragmentierte Daten enthält? Oder ist ein Iso-Image kein Image?
--
Ist es nicht genau das, was ich gesagt habe, das es ebene _nicht_ fragmentiert?
Ja.
Der einzige, der davon redet, bist du selbst. Wieso du sowas reininterpretierst, nur weil ich dieses Beispiel als _eines_von_vielen_ Imagearten angeführt hab, versteh ich nicht. Aber jeder liest das, was er lesen will.
Bitte, ich weiß nicht was du willst. Als Image verstehe ich das exakte, binäre Abbild eines Dateisystems. Das man z.B. mit dd erstellen kann. Und iso-CD-Abbilder wären dann Abbilder der entsprechenden CD, auch wenn es die physisch gar nicht gibt. Wenn ich ein Image eines ext3-Dateisystems anlege habe ich aber immer ein resultierendes ext3-Tmage, das folglich genauso fragmentiert ist. Wenn ich eine CD brennen würde oder aus den dateien sonstwie eine iso erstellen würde, hätte ich ein komplett neues Dateisystem erstellt, also kein Image von diesem Dateisystem erstellt, sondern eben ein neues Image erstellt.
Jonathan
Als Image verstehe ich das exakte, binäre Abbild eines Dateisystems.
Nochmal zum mitmeisseln: Nur, weil du eine falsche Ansicht vertrittst, heisst es nicht, das andere Aussagen falsch sind.
Und nur nebenbei, ich kann ein Iso9660-Image auch aus Daten erzeugen, die _nicht_ bereits auf einer CD liegen. Vielleicht willst du dir nochmal die Bedeutung von "Image" durchlesen und zwar nicht auf die begrenzte Ansicht hin, es bezieht sich lediglich auf ein CLusterabbild einer Festplatte.
Hallo Multi,
Und nur nebenbei, ich kann ein Iso9660-Image auch aus Daten erzeugen, die _nicht_ bereits auf einer CD liegen.
Auch das ist klar. Und auch da habe ich noch nichts anderes behauptet, eher im gegenteil.
Vielleicht willst du dir nochmal die Bedeutung von "Image" durchlesen und zwar nicht auf die begrenzte Ansicht hin, es bezieht sich lediglich auf ein CLusterabbild einer Festplatte.
Auch das habe ich nie behauptet.
Jonathan
Hallo Multi,
Als Image verstehe ich das exakte, binäre Abbild eines Dateisystems.
Nochmal zum mitmeisseln: Nur, weil du eine falsche Ansicht vertrittst, heisst es nicht, das andere Aussagen falsch sind.
Und nochmal ein Nachtrag: Ich sage hier weder das das vorhandene Dateisystem auf einer Festplatte sein muss, noch das es irgendwo existieren muss. Man kann ein Image von mir aus auch als Container für eine virtuelle Partition betrachten.
Vielleicht hörst du bitte mal auf in meine Aussagen irgendein Zeug reinzudeuten.
Jonathan
Moin!
Aha. Und wenn ich jetzt alle Dateien in dieses Image kopiere, sind die Daten immer noch fragmentiert? Ich hab nie behauptet, du sollst die Festplatte auf Clusterebene kopieren, sondern du sollst den Platteninhalt per dd kopieren.
dd öffnet eine Datei, liest daraus eine gewisse Anzahl Bytes, und schreibt die in eine andere Datei.
Wenn du mit dd ein Partitionsdevice (/dev/hda2) oder gar ein Plattendevice (/dev/hdb) als Quelldatei benutzt, dann erstellst du vom fragmentierten Zustand dort eine identische Kopie, die auch dann noch fragmentiert bleibt, wenn du sie dann wieder zurückspielst.
Wenn du dd auf im Dateisystem existierende Dateien anwendest, kannst du stattdesse auch einfach cp zum Kopieren verwenden. Das dürfte deutlich einfacher zu nutzen sein.
- Sven Rautenberg
dd öffnet eine Datei, liest daraus eine gewisse Anzahl Bytes, und schreibt die in eine andere Datei.
Richtig
Wenn du mit dd ein Partitionsdevice (/dev/hda2) oder gar ein Plattendevice (/dev/hdb) als Quelldatei benutzt, dann erstellst du vom fragmentierten Zustand dort eine identische Kopie, die auch dann noch fragmentiert bleibt, wenn du sie dann wieder zurückspielst.
Genau das, was ich gesagt hab, danke für deine Bestätigung
Wenn du dd auf im Dateisystem existierende Dateien anwendest, kannst du stattdesse auch einfach cp zum Kopieren verwenden. Das dürfte deutlich einfacher zu nutzen sein.
Du hälst also einen Befehl, der beim Ablegen der Dateien diese wieder fragmentiert, als sinnvoller? Du solltest dir nochmal den Unterschied zwischen dd und cp durchlesen.
你好 Multi,
Wenn du mit dd ein Partitionsdevice (/dev/hda2) oder gar ein Plattendevice (/dev/hdb) als Quelldatei benutzt, dann erstellst du vom fragmentierten Zustand dort eine identische Kopie, die auch dann noch fragmentiert bleibt, wenn du sie dann wieder zurückspielst.
Genau das, was ich gesagt hab, danke für deine Bestätigung
Du sagtest: ein dd-Image wieder zurückspielen defragmentiert. Das ist nicht der Fall.
再见,
克里斯蒂安
Du sagtest: ein dd-Image wieder zurückspielen defragmentiert. Das ist nicht der Fall.
Ich sagte, das _Erzeugen_und_Zurückspielen_ eines Images mit dd defragmentiert. Beim Zurückspielen werden die Daten dann nicht fragmentiert, wenn das Dateisystem komplett "sauber" ist und die Daten nicht wieder zerlegt.
Ich habe aber auch gesagt, das dieser Weg nicht wirklich praktikabel ist.
你好 Multi,
Beim Zurückspielen werden die Daten dann nicht fragmentiert, wenn das Dateisystem komplett "sauber" ist und die Daten nicht wieder zerlegt.
Du liegst da einem Irrtum auf, ein dd-Image hat mit dem Dateisystem nichts zu tun bzw. schreibt das alte Dateisystem über das neue.
Wenn du meinst, man kann jede einzelne Datei per dd einlesen und wieder zurückschreiben und so eine Defragmentierung vornehmen: ja, aber das ist eher kopieren, aber kein Image.
再见,
克里斯蒂安
Hallo Christian,
Beim Zurückspielen werden die Daten dann nicht fragmentiert, wenn das Dateisystem komplett "sauber" ist und die Daten nicht wieder zerlegt.
Du liegst da einem Irrtum auf, ein dd-Image hat mit dem Dateisystem nichts zu tun bzw. schreibt das alte Dateisystem über das neue.
ich glaube, ich verstehe langsam, was "Multi" im Sinn hat: Ein neues, leeres Image erstellen, das zum vorhandenen Dateisystem kompatibel ist, dann dieses Image mounten, alle Dateien einzeln hineinkopieren, und das ganze Image dann per dd auf das Original-Dateisystem zurückspielen.
Das könnte wohl funktionieren - aber dann sind wir wieder beim einfachen Defragmentieren durch Kopieren.
Schönen Sonntag noch,
Martin
Das könnte wohl funktionieren - aber dann sind wir wieder beim einfachen Defragmentieren durch Kopieren.
Deshalb ja meine Aussage
Zugegeben, kein überaus pratikabler Weg
Vorallem, weil man die dateisysteminterne Verwaltung torpediert.
Desweiteren ist diese Methode nicht auf meinem Mist gewachsen sondern wurde im Usenet diskutiert. Allerdings mit mehr Fachwissen als von einigen hier ;)
你好 Martin,
ich glaube, ich verstehe langsam, was "Multi" im Sinn hat: Ein neues, leeres Image erstellen, das zum vorhandenen Dateisystem kompatibel ist, dann dieses Image mounten, alle Dateien einzeln hineinkopieren, und das ganze Image dann per dd auf das Original-Dateisystem zurückspielen.
Das ist völlig sinnlos, denn das ist äquivalent zu einem mkfs mit anschließendem cp -Rp.
再见,
克里斯蒂安
Hallo,
Dann dürften sie nicht "image" (Abbild) nennen. Unter einem Image verstehe ich eine Technik, mit der ich ein bitgetreues Abbild erzeugen kann.
Willst du mir jetzt erzählen, das ein iso9660-Image fragmentierte Daten enthält?
Was hat das damit zu tun?
Wie kommst Du denn an ein ISO9660-Image? Entweder Du sagst Deinem Brennprogramm "Ich will aus den und den Dateien ein ISO9660-Image erstellen" und das macht es dann oder Du ziehst Dir ein Image von einer bestehenden CD.
Im ersten Fall hast Du ein 1:1-Abbild des Inhalts der Datenspur der CD, die Du aus dem Image erstellen könntest (sprich: wenn Du Dein erstelltes ISO-9660-Image auf eine CD brennst, dann ist der Nutzdateninhalt der dort vorhandenen Datenspur identisch mit dem ISO9660-Image). Im zweiten Fall ist das Image identisch mit den Nutzdaten der Datenspur der bereits vorhandenen CD.
ISO9660 ist ein Readonly-Dateisystem (Multisession heißt ja nur, dass etwas "hinten rangehängt" wird), unterstützt daher auch keine fragmentierten Dateien.
Viele Grüße,
Christian
Was hat das damit zu tun?
Ich vergleiche "Image" mit "Image", da behauptet wurde, ein Image ist ein 1zu1-Clusterabbild, was ich mit dem Vergleich auf Iso9660 widerlege.
Wie kommst Du denn an ein ISO9660-Image? Entweder Du sagst Deinem Brennprogramm "Ich will aus den und den Dateien ein ISO9660-Image erstellen" und das macht es dann oder Du ziehst Dir ein Image von einer bestehenden CD.
Richtig. Und ebenso erkläre ich einem anderen Imageprogramm, wie das Image aussehen soll.
ISO9660 ist ein Readonly-Dateisystem (Multisession heißt ja nur, dass etwas "hinten rangehängt" wird), unterstützt daher auch keine fragmentierten Dateien.
Und was hat das mit dem Thema zu tun? Es ging eben genau um die Erzeugung eines Images ohne fragmentierte Daten. Nicht darum, ob ein bestimmtes Image read-only ist oder nicht.
Moin!
Was hat das damit zu tun?
Ich vergleiche "Image" mit "Image", da behauptet wurde, ein Image ist ein 1zu1-Clusterabbild, was ich mit dem Vergleich auf Iso9660 widerlege.
Nicht wirklich. Ein ISO9660-Image ist ein 1:1-Abbild eines optischen Datenträgers.
Beim Erstellen solch eines Images werden Dateien dorthinein KOPIERT - aber eben nicht in einer 1:1-Blockabbild-Aktion, bei der die Fragmentierung mitübertragen werden würde.
Wie kommst Du denn an ein ISO9660-Image? Entweder Du sagst Deinem Brennprogramm "Ich will aus den und den Dateien ein ISO9660-Image erstellen" und das macht es dann oder Du ziehst Dir ein Image von einer bestehenden CD.
Richtig. Und ebenso erkläre ich einem anderen Imageprogramm, wie das Image aussehen soll.
Das Herstellen eines ISO9660-Images läßt sich mit dd aber nur schwierig bewerkstelligen.
- Sven Rautenberg
Nicht wirklich. Ein ISO9660-Image ist ein 1:1-Abbild eines optischen Datenträgers.
Achja? Bei mir wird idR erst _nach_ dem Erzeugen des Images ein optischer Datenträger daraus. Aber du hast Recht, dadurch wird es zu einem 1:1 Abbild.
Beim Erstellen solch eines Images werden Dateien dorthinein KOPIERT - aber eben nicht in einer 1:1-Blockabbild-Aktion, bei der die Fragmentierung mitübertragen werden würde.
Schön, das du endlich verstanden hast, was ich seit zig Postings mehrfach erzählt hab. :)
Das Herstellen eines ISO9660-Images läßt sich mit dd aber nur schwierig bewerkstelligen.
Da du der einzige bist, der dieses erwähnt, brauch ich dazu ja nichts zu sagen. Ich vermute, du hast es ausprobiert, nur um es erwähnen zu können?
Yerf!
Das Herstellen eines ISO9660-Images läßt sich mit dd aber nur schwierig bewerkstelligen.
Da du der einzige bist, der dieses erwähnt, brauch ich dazu ja nichts zu sagen. Ich vermute, du hast es ausprobiert, nur um es erwähnen zu können?
*DU* bist hier der einzige, der behauptet man könnte dd für solche Zwecke benutzen...
Also erleuchte uns, sage uns, wie wir ISO-9660 Images erstellen können (ohne ein 1:1 Image einer CD zu ziehen) oder eine Festplattenpartition defragmentiern können, *nur* mit dd!
Was du suchst ist wohl eher cp oder tar...
dd ist nunmal dazu da, eine 1:1 Abbildung zu erstellen, da es durchaus Sinnvoll sein kann die "Fragmentierung" zu erhalten (evtl hat sie ja noch einen betimmten Zweck).
Fragmentierung aufheben kann man nur durch fileweise umkopieren auf ein frisches Dateisystem, evtl. geht das auch in dem man dd auf die einzelnen Dateien anwendet (habs noch nicht probiert, da absolut abwegig), aber eigentlich ist cp dafür gedacht.
Gruß,
Harlequin
*DU* bist hier der einzige, der behauptet man könnte dd für solche Zwecke benutzen...
Dann zitiere mich, wo ich sowas behauptet habe.
Yerf!
Dann zitiere mich, wo ich sowas behauptet habe.
Eine 100%ige Defragmentierung ist dadurch zu erreichen, per dd ein Image zu erzeugen, die komplette Platte zu löschen und das Image zurückzuspielen.
Gruß,
Harlequin
Eine 100%ige Defragmentierung ist dadurch zu erreichen, per dd ein Image zu erzeugen, die komplette Platte zu löschen und das Image zurückzuspielen.
Und wo steht da was von einem Iso9660-Image?
Yerf!
Eine 100%ige Defragmentierung ist dadurch zu erreichen, per dd ein Image zu erzeugen, die komplette Platte zu löschen und das Image zurückzuspielen.
Und wo steht da was von einem Iso9660-Image?
Durch dein sehr knappes Zitieren hab ich dich jetzt auf eine andere Aussage von dir bezogen...
Aber ok, hier vergleichst du das ganze mit ISO9660 und erzählst jede Menge Quatsch:
dd kann eine Festplatte nur clusterbasiert auslesen und auf diese Weise ein Image der aktuellen Struktur erstellen. Es ist *nicht* in der Lage aus Einzelfiles eine *neues* Image zu erstellen. Könnte es dies, so könnte man damit auch CD-Images erstellen.
Gruß,
Harlequin
Aber ok, hier vergleichst du das ganze mit ISO9660 und erzählst jede Menge Quatsch:
Ich will aber von dir wissen, wo ich behauptet habe, mit dd kann man iso9660-Images erzeugen. Denn genau das hast du behauptet bzw. wir sogar vorgeworfen.
Desweiteren wurde schon mehrfach festgestellt, das dd nicht nur in der Lage ist, ein Clusterabbild eines Devices zu machen. Mit dem Lesen hast du es nicht so, oder?
Ich klink mich hier jetzt aus. Denn mit Leuten, die irgendwas lesen, was nicht dasteht und dan nichtmal ihren Fehler zugeben können, diskutier ich nicht. Du kannst deine Vorwürfe nicht belegen und dadurch bist du für mich nicht glaubwürdig.
Yerf!
Ich will aber von dir wissen, wo ich behauptet habe, mit dd kann man iso9660-Images erzeugen. Denn genau das hast du behauptet bzw. wir sogar vorgeworfen.
Ok, das hast du so nicht gesagt, stimmt. Du hast es nur sehr unpassend als Vergleich mit reingezogen (unpassend, eben weil dd nichts mit ISO-9660 am Hut hat).
Allerdings gehts du ebenfalls nicht auf meinen anderen Punkt ein, wie *genau* du jetzt mittels dd defragmentieren willst.
Desweiteren wurde schon mehrfach festgestellt, das dd nicht nur in der Lage ist, ein Clusterabbild eines Devices zu machen. Mit dem Lesen hast du es nicht so, oder?
Ja, man kann auch ein Cluster-Abbild einer einzelnen Datei erstellen. Das hilft dir wie genau weiter?
Ich klink mich hier jetzt aus. Denn mit Leuten, die irgendwas lesen, was nicht dasteht und dan nichtmal ihren Fehler zugeben können, diskutier ich nicht. Du kannst deine Vorwürfe nicht belegen und dadurch bist du für mich nicht glaubwürdig.
Der einzige der hier keinen Fehler zugeben will bist du. Bisher hast du auch noch nicht belegt, das man mittels dd derfragmentieren kann. Und das war deine Behauptung!
Gruß,
Harlequin
Hallo,
Ich klink mich hier jetzt aus.
das war die erste vielversprechende Aussgae von dir im ganzen Thread.
Aber wahrscheinlich ebensowenig zutreffend wie der Rest auch.
Ciao,
Martin
Hallo,
Dann zitiere mich, wo ich sowas behauptet habe.
Dein erstes Posting in diesem Thread enthält folgenden Satz:
Eine 100%ige Defragmentierung ist dadurch zu erreichen, per dd ein Image zu erzeugen, die komplette Platte zu löschen und das Image zurückzuspielen.
Nachdem Dir nun heftig widersprochen wurde, versuchst Du Dich über irgendwelche aberwitzigen Ideen herauszuwinden (nach dem Motto, man könnte ja dd als cp-Ersatz verwenden und es einzeln auf die Dateien losjagen und die Dateien so in ein frisches Image zu ziehen), die zwar an sich technisch nicht falsch sind, aber NIEMALS auch nur ANSATZWEISE dem entsprechen, was man selbst mit sehr viel Phantasie aus eben diesem Satz herausinterpretieren könnte.
Viele Grüße,
Christian
Dein erstes Posting in diesem Thread enthält folgenden Satz:
Eine 100%ige Defragmentierung ist dadurch zu erreichen, per dd ein Image zu erzeugen, die komplette Platte zu löschen und das Image zurückzuspielen.
An dich auch die Frage, wo steht da was von einem Iso9660-Image. wie von Harlequin behauptet?
Moin!
Dein erstes Posting in diesem Thread enthält folgenden Satz:
Eine 100%ige Defragmentierung ist dadurch zu erreichen, per dd ein Image zu erzeugen, die komplette Platte zu löschen und das Image zurückzuspielen.
An dich auch die Frage, wo steht da was von einem Iso9660-Image. wie von Harlequin behauptet?
Da steht gar nichts von einem ISO9660-Image. Das ist ja obendrein noch das Problem. Du beziehst dich auf Images allgemein, nicht mal nur auf ISO-Images speziell.
- Sven Rautenberg
Moin!
Beim Erstellen solch eines Images werden Dateien dorthinein KOPIERT - aber eben nicht in einer 1:1-Blockabbild-Aktion, bei der die Fragmentierung mitübertragen werden würde.
Schön, das du endlich verstanden hast, was ich seit zig Postings mehrfach erzählt hab. :)
Das Image wird ja aber nicht durch Anwendung von dd auf eine vorhandene Festplattenpartition hergestellt.
Das Herstellen eines ISO9660-Images läßt sich mit dd aber nur schwierig bewerkstelligen.
Da du der einzige bist, der dieses erwähnt, brauch ich dazu ja nichts zu sagen. Ich vermute, du hast es ausprobiert, nur um es erwähnen zu können?
Du kannst natürlich mit dd, welches in einer langen Liste von detaillierten Anweisungen aufgerufen wird, stückchenweise ein ISO9660-Image zusammenfriemeln.
Es dürfte deutlich einfacher sein, einem auf genau diesen Zweck abgestimmten Programm einfach eine Liste der zu verwendenden Dateien zu übergeben. Dann muß man sich um die Herstellung der Metastrukturen des Dateisystems auch keine Gedanken machen, während die Verwendung von dd diese Strukturen nur durch höchst komplexe Einzeloperationen produzieren würde.
Du brauchst dir ja nur mal die manpage zu dd anzugucken:
---schnipp---
NAME
dd - convert and copy a file
SYNOPSIS
dd [--help] [--version] [if=file] [of=file] [ibs=bytes] [obs=bytes]
[bs=bytes] [cbs=bytes] [skip=blocks] [seek=blocks] [count=blocks]
[conv={ascii, ebcdic, ibm, block, unblock, lcase, ucase, swab, noerror,
notrunc, sync}]
DESCRIPTION
dd copies a file (from standard input to standard output, by default)
using specific input and output blocksizes, while optionally performing
conversions on it.
---schnapp---
Die Parameter von dd erwarten Dateinamen (if, of), die Angabe von Bytes oder von Blocks - und die Konversionsmöglichkeiten beziehen sich allesamt auf den Dateiinhalt.
Wobei "Datei" im Unix-Sinn gemeint ist. /dev/hda2 ist die Devicedatei der zweiten primären Partition der ersten IDE-Festplatte. Da liest (oder schreibt) man seriell alle Blöcke der Festplatte, egal welche Bedeutung (insbesondere im Sinne des enthaltenen Dateisystems) diese haben. Da defragmentiert nichts, wenn man mit dd liest.
- Sven Rautenberg
Das Image wird ja aber nicht durch Anwendung von dd auf eine vorhandene Festplattenpartition hergestellt.
Stimmt. Meine Rede seit dem ersten Post. Hat lange gedauert, bis es zu dir durchgedrungen ist.
Du kannst natürlich mit dd, welches in einer langen Liste von detaillierten Anweisungen aufgerufen wird, stückchenweise ein ISO9660-Image zusammenfriemeln.
Also es geht jetzt doch? Du solltest dich langsam mal entscheiden.
Wobei "Datei" im Unix-Sinn gemeint ist.
Richtig. Also eine oder mehrere "echte" Dateien oder auch ein Device oder STDIN/STDOUT/STDERR usw. usw.
Moin!
Das Image wird ja aber nicht durch Anwendung von dd auf eine vorhandene Festplattenpartition hergestellt.
Stimmt. Meine Rede seit dem ersten Post. Hat lange gedauert, bis es zu dir durchgedrungen ist.
Deine erste Aussage zu Defragmentierung, dd und Images war:
"Eine 100%ige Defragmentierung ist dadurch zu erreichen, per dd ein Image zu erzeugen, die komplette Platte zu löschen und das Image zurückzuspielen."
Und diese Aussage ist schlichtweg falsch. Egal wie du dich jetzt drehst und wendest.
Alternativ kannst du ja mal zeigen, mit welcher Befehlszeile du mittels dd eine Defragmentierung erreichst.
- Sven Rautenberg
你好 Sven,
ich verstehe nicht, warum du mit dem noch diskutierst - bringt doch eh nichts, windet sich doch eh wieder 'raus.
再见,
克里斯蒂安
Alternativ kannst du ja mal zeigen, mit welcher Befehlszeile du mittels dd eine Defragmentierung erreichst.
Beispiel für ca. 1,5GB, für ein grösseres Image entsprechend anpassen.
dd if=/dev/zero of=image bs=1m count=1536
cp -Rf ~/* # Als Beispiel wird das aktuelle Homeverzeichnis verwendet
-- hier dann die Partition aufräumen/löschen/formatieren --
dd if=image of=/dev/hdX # Je nachdem, wo das Homeverzeichnis liegt.
cp -Rf ~/*
q.e.d.
q.e.d.
Was denn? Das der Befehl nur halb ist? Das ich das Image vorher mounten muss? Das ich zusätzlich zu dd noch ein cp brauche?
Ja, das stimmt alles. und ich habe nicht einmal das Gegenteil davon behauptet. Das ich von dir und anderen aber nicht erwarten kann, zuzugeben, das es funktioniert, ist mir klar.
BTW: Wenn du den Unterschied zwischen dem Kopieren auf ein Device und dem Kopieren in ein Image nichts selbst erkennst, ist sowieso jedes weitere Wort überflüssig.
Yerf!
Was denn? Das der Befehl nur halb ist?
Zumindest funktioniert das so erst mal nicht, da fehlt noch ne ganze Menge.
Das ich das Image vorher mounten muss?
Nicht nur mounten, auch noch formatieren. Der dd erzeugt dir auf diese weise nur eine Datei mit 1.5GB an Null-Bytes. Das geht auch anders...
Das ich zusätzlich zu dd noch ein cp brauche?
Der Punkt ist, dass das Defragmentieren aber im cp-Schritt passiert und dd überflüssig ist.
Ja, das stimmt alles. und ich habe nicht einmal das Gegenteil davon behauptet. Das ich von dir und anderen aber nicht erwarten kann, zuzugeben, das es funktioniert, ist mir klar.
Du hast behauptet man könne mit dd defragmentieren. Das ist in etwa so wie wenn ich jetzt behaupte ich könne mit Hammer und Meisel defragmentieren. Ich hau die Platte kaputt und spiel dann die Bandsicherung fileweise auf eine neue frisch formatierte Festplatte... und siehe da: Daten sind defragmentiert!
BTW: Wenn du den Unterschied zwischen dem Kopieren auf ein Device und dem Kopieren in ein Image nichts selbst erkennst, ist sowieso jedes weitere Wort überflüssig.
Du scheinbar auch nicht... wie kopierst du in ein Image? Es mounten und dann in das gemountete Device kopieren? ...das war zumindest dein Vorschlag.
Ein direktes kopieren ins Image wäre analog zu einer CD-Software aus Einzelfiles ein Image aufzubauen, aber das kann dd nicht.
Gruß,
Harlequin
Ok, da du der letzte bist, der es noch nicht kapiert hat, dürfte klar sein, das es an dir liegt. Also sparen wir uns weitere Worte,
denn offensichtlich kapierst du die Zusammenhänge auch dann nicht, wenn sie andere weiter ausgeführt haben.
Und da du offensichtlich das letzte Wort haben willst, poste einfach nochmal auf mich, ich werds nicht kommentieren.
Ok, da du der letzte bist, der es noch nicht kapiert hat, dürfte klar sein, das es an dir liegt. Also sparen wir uns weitere Worte,
denn offensichtlich kapierst du die Zusammenhänge auch dann nicht, wenn sie andere weiter ausgeführt haben.Und da du offensichtlich das letzte Wort haben willst, poste einfach nochmal auf mich, ich werds nicht kommentieren.
Das ist ein feiner Zug von Dir!
Dein (Nicht-)Verständnis mit ansehen zu müssen, war nervig genug...
Gruß
Reiner
Hallo,
dd if=/dev/zero of=image bs=1m count=1536
Damit aus dem Subthread hier doch noch was sinnvolles wird:
Das ist übrigens eine GANZ schlechte Idee, eine große Datei anzulegen, die später mal für ein Image herhalten soll. Mit etwas Perl auf der Kommandozeile kann man das ganze nämlich VIEL schneller und sinnvoller erledigen:
perl -e 'open F, ">test.img" ; truncate F, 1536*1024*1024;'
Der Befehl erzeugt eine Datei 'test.img', die 1536 MiB groß ist. Allerdings hat der Befehl den Vorteil, dass die Datei als sogenannte "Sparse-Datei" angelegt wird, d.h. erst einmal GAR KEINEN Platz auf der Platte verbraucht. Außerdem kann der Befehl sofort zurückkehren und man muss nicht lange warten.
Da der Kernel bei Sparse-Dateien beim Lesen automatisch 0-Bytes ergänzt, wo kein tatsächlicher Inhalt da ist, spart man sich /dev/zero komplett. Nun kann man aus dieser kleinen großen leeren Datei ein Image machen, indem man ein Dateisystem anlegt, z.B. mit »mke2fs test.img«. Das kann man dann ganz normal mounten und die Dateien reinkopieren. Das Image verbraucht dann nur soviel Platz, wie man auch tatsächlich Dateien darin anlegt.
Viele Grüße,
Christian
Das ist übrigens eine GANZ schlechte Idee, eine große Datei anzulegen, die später mal für ein Image herhalten soll. Mit etwas Perl auf der Kommandozeile kann man das ganze nämlich VIEL schneller und sinnvoller erledigen:
Deshalb auch mein Satz im allerersten Posting:
Zugegeben, kein überaus pratikabler Weg, aber machbar ist es.
Und das nicht alles, was machbar ist, auch sinnvoll ist, darüber dürften wir uns einig sein ;)
Moin!
Alternativ kannst du ja mal zeigen, mit welcher Befehlszeile du mittels dd eine Defragmentierung erreichst.
Beispiel für ca. 1,5GB, für ein grösseres Image entsprechend anpassen.
dd if=/dev/zero of=image bs=1m count=1536
Statt des Anlegens einer Image-Partition häng' ich temporär eine weitere Festplatte ins System oder ordne direkt bestehenden, aber ungenutzten Festplattenplatz mit LVM2 der neuen Partition zu.
Das spart mir den Einsatz von dd.
cp -Rf ~/* # Als Beispiel wird das aktuelle Homeverzeichnis verwendet
Dann kopiere ich. Genau wie du.
Und schon sieht man: Defragmentieren braucht dd nicht (wie du behauptet hast), aber es braucht das dateiweise Kopieren (wie ich behauptet habe).
dd if=image of=/dev/hdX # Je nachdem, wo das Homeverzeichnis liegt.
Diesen Schritt kann man sich dann ggf. sogar sparen, indem man einfach die alte Partition umountet und die neue Partition mountet.
- Sven Rautenberg
你好 Multi,
wenn du ein Image zurückspielst, hast du wieder ein exaktes Abbild aller vorherigen Strukturen. Einschließlich der vorher herrschenden Unordnung und eventueller Dateisystemfehler.
Wenn ich das Image per dd erzeugt, nicht. Dieses Image ist Dateibasiert und nicht Clusterbasiert. Wenn ich mich nicht täusche, arbeiten Norton Ghost u.a. auch in dieser Art.
Definitiv nicht. Dazu müsste dd ja das Quell-Dateisystem kennen. Du kannst aber von Datenträgern mit beliebigen Dateisystemen Images erstellen, ich z. B. habe letztens ein Image von einer NTFS-Partition erstellt in einer Busybox - die kann kein NTFS ;)
再见,
克里斯蒂安
Hallo,
Wenn ich das Image per dd erzeugt, nicht. Dieses Image ist Dateibasiert und nicht Clusterbasiert. Wenn ich mich nicht täusche, arbeiten Norton Ghost u.a. auch in dieser Art.
Ich habe keine Ahnung, wo Du das herhast. dd legt - wie schon mehrfach gesagt - ein 1:1-Abbild der Partition an, auf die Du es loslässt. Da bleibt alle Fragmentierung vollständig erhalten.
Es gibt Tools (wie auch Norton Ghost), die wissen, wie das Dateisystem aufgebaut ist, von dem sie ein Image ziehen, und deswegen unbenutzte Bereiche auslassen können. Damit werden die Image-Kopien kleiner, weil nur der tatsächlich genutzte Speicherplatz verwendet werden muss (Beispiel: Auf einer 40 GiB-Partition sind nur 20 GiB belegt - bei "intelligeten" Tools ist das Image nur 20 GiB groß, bei dd ist's 40 GiB groß). Da die Tools aber einen Teufel tun werden, die vorhandenen Datenstrukturen zu ändern (!), wird auch nach dem Zurückspielen die Fragmentierung erhalten bleiben. Nützt Dir also nicht.
Viele Grüße,
Christian
Moin!
Da die Tools aber einen Teufel tun werden, die vorhandenen Datenstrukturen zu ändern (!), wird auch nach dem Zurückspielen die Fragmentierung erhalten bleiben. Nützt Dir also nicht.
Richtig. In der Position der Daten steckt ja unter Umständen eine sehr wichtige Position. Man hat schon Kopierschütze damit realisiert - oder irgendein Programm speichert nicht den Pfadnamen zur Datei, sondern direkt die anzusteuernde Blocknummer. Image-Programme dürfen von daher nicht einfach in die Fragmentierung eingreifen.
- Sven Rautenberg
Ich habe keine Ahnung, wo Du das herhast. dd legt - wie schon mehrfach gesagt - ein 1:1-Abbild der Partition an, auf die Du es loslässt.
Die Manpage sagt mir aber was anderes. Und zwar, das ich auch einzelene Dateien angeben kann, inkl. Wildcards.
Nur weil dd _auch_ komplette Devices abbilden kann, heisst es nicht, dass die Funktionalität dahin eingeschränkt ist.
Zitat:
if=DATEI aus DATEI statt von der Standardeingabe lesen
你好 Multi,
Zitat:
if=DATEI aus DATEI statt von der Standardeingabe lesen
Das liegt daran, dass unter Linux alles eine Datei ist, auch Devices ;)
再见,
克里斯蒂安
wenn du ein Image zurückspielst, hast du wieder ein exaktes Abbild aller vorherigen Strukturen. Einschließlich der vorher herrschenden Unordnung und eventueller Dateisystemfehler.
Wenn ich das Image per dd erzeugt, nicht. Dieses Image ist Dateibasiert und nicht Clusterbasiert. Wenn ich mich nicht täusche, arbeiten Norton Ghost u.a. auch in dieser Art.
Sorry, aber das ist Quark hoch drei!
dd weiß überhaupt nichts über die Struktur der Daten.
Du kannst höchsten Blockzahl und -größe angeben, um so z.B. nur den MBR zu kopieren.
Gruß
Reiner
Ich bin ja fassziniert, wie ein Vorschlag, der im Ausgangsposting als
Zugegeben, kein überaus pratikabler Weg
Bezeichnet wurde, mit solcher Hingabe diskutiert wird.
Um die Sache für mich abzuschliesen für jeden, den es interessiert:
Ich habe gehört, das unter Linux keine Defragmentierung nötig sei. Stimmt das, oder ist das unfug.
Jedes Dateisystem fragmentiert, die einen mehr, die anderen weniger. ext2, ext3, reiserfs z.B. recht wenig, Fat extrem, NTFS geht so.
Bei ext4 ist aber ein Defragmentierer angekündigt der ständig als Daemon im Hintergrund läuft.
Sinnvoll, da immer Fragmente auftreten, wenn das Dateisystem selbst aber nur wenig fragmentiert, hat natürlich auch der Daemon wenig zu tun und frisst dadurch nur wenig Performance.
Hi Multi,
Sinnvoll, da immer Fragmente auftreten, wenn das Dateisystem selbst aber nur wenig fragmentiert, hat natürlich auch der Daemon wenig zu tun und frisst dadurch nur wenig Performance.
Da klingt vernünftig. Die Preisfrage wird sein, was passiert, wenn der Deamon arbeitet, und gerade dann ist Stromausfall. Soll ja wärend eines Defragmentiervorganges nicht so gesund für den Computer sein :-)
Grüsse gary
Hallo,
Die Preisfrage wird sein, was passiert, wenn der Deamon arbeitet, und gerade dann ist Stromausfall. Soll ja wärend eines Defragmentiervorganges nicht so gesund für den Computer sein :-)
da ist die Defragmentierung nicht kritischer als das reguläre Schreiben einer Datei. Beim Anlegen und Beschreiben einer neuen Datei finden ja mehrere Teilvorgänge statt, die miteinander verzahnt sind:
* Suchen eines freien Verzeichniseintrags
* Suchen des ersten freien Sektors für die Nutzdaten
* Markieren dieses Sektors als "belegt"
* Erzeugen eines Verzeichniseintrags
* Eintragen des Startsektors für die Datei im Verzeichniseintrag
* Schreiben des ersten Sektors Nutzdaten
* Aktualisieren der Dateigröße im Verzeichnis
* ...
Diese Prozesskette könnte durch unverhergesehene Ereignisse jederzeit unterbrochen werden, und je nachdem, wann diese Unterbrechung stattfindet, hinterlässt sie ein fehlerhaftes (aber reparierbares) Dateisystem oder auch nicht.
Genauso ist es beim Defragmentieren, wenn es ordentlich implementiert ist. Das Dümmste, was dabei passieren kann, sind Sektoren, die als "belegt" markiert, aber noch nicht (oder nicht mehr) mit dem Verzeichniseintrag verknüpft sind. Das lässt sich leicht wieder in Ordnung bringen.
So long,
Martin (der unter DOS schon ein robustes FAT-Defragmentierungs-Tool geschrieben hat)
Da klingt vernünftig. Die Preisfrage wird sein, was passiert, wenn der Deamon arbeitet, und gerade dann ist Stromausfall. Soll ja wärend eines Defragmentiervorganges nicht so gesund für den Computer sein :-)
Es besteht das gleiche Risiko, wie bei jedem Scrheibvorgang. Es kann zu Datenverlust kommen oder im Extremfall zu einer Beschädigung der Festplatte (zumindest ist mir das bei ner alten Platte vor Jahren mal passiert, ob das heute noch passieren kann, weiss ich nicht).
Aufgrund der integrierten Sicherheitsmechanismen von ext4 (was bisher angekündigt ist), dürfte das Risiko eines Datenverlustes ziemlich gering sein.
Hi,
Ich habe gehört, das unter Linux keine Defragmentierung nötig sei. Stimmt das, oder ist das unfug.
ich habe nicht viel Ahnung von dem Thema, aber es gibt eine interessante Diskussion (auf Englisch) zu diesem Thema: Multiplatform! JKdefrag on Linux? Das Forum gehört Jeroen Kessels, der ein Open-Source-Defragmentierungsprogramm für die Windows-NT-Reihe geschrieben hat. Ein Benutzer fragte, ob es dieses Programm (JKDefrag) auch für Linux geben werde. Jeroen hat sich auch selbst mehrmals in diesem Thread geäußert, und auch die Frage, ob Linux überhaupt Defragmentierung brauche, wird diskutiert, ohne jedoch zu einem Konsens zu kommen.
Gruß
Def
Hallo,
Ich habe gehört, das unter Linux keine Defragmentierung nötig sei. Stimmt das, oder ist das unfug.
[...] es gibt eine interessante Diskussion (auf Englisch) zu diesem Thema: Multiplatform! JKdefrag on Linux? (dort wird) die Frage, ob Linux überhaupt Defragmentierung brauche, wird diskutiert, ohne jedoch zu einem Konsens zu kommen.
ohne die Diskussion jetzt lesen zu wollen, hört sich das sehr lustig an.
;-)
Viele Grüße,
Reiner
Hallo Reiner,
ohne die Diskussion jetzt lesen zu wollen, hört sich das sehr lustig an.
;-)
beziehst Du Dich auf den Inhalt oder die etwas missglückte Formulierung meines Postings (dass die Frage nicht zu einem Konsens kommt)? Ich kann letzteres nur aufgrund des Ironie-Smilings in Deinem Posting vermuten...
Gruß
Def
Hallo Reiner,
ohne die Diskussion jetzt lesen zu wollen, hört sich das sehr lustig an.
;-)beziehst Du Dich auf den Inhalt oder die etwas missglückte Formulierung meines Postings (dass die Frage nicht zu einem Konsens kommt)? Ich kann letzteres nur aufgrund des Ironie-Smilings in Deinem Posting vermuten...
wie gesagt, ich habe es nicht gelesen - wir kamen ja hier schon nicht weiter...
Zumindest gibt es unbelehrbare Personen, aber egal.
Ja, ich fand Deinen Beitrag einfach witzig!
lg
Reiner
Hallo Reiner,
wie gesagt, ich habe es nicht gelesen - wir kamen ja hier schon nicht weiter...
Zumindest gibt es unbelehrbare Personen, aber egal.
Ja, ich fand Deinen Beitrag einfach witzig!
ah, okay, ich glaube, ich weiß jetzt, was Du meinst. ;-)
Gruß
Def
