Leopard Systempflege

[secretchord]

Weia, schon wieder MacOS 7/8/9. "Erste Hilfe" war das - ähem - "Festplattendienstprogramm" von Mac OS 7/8/9. Die Infos auf der Seite haben nichts mit OS X zu tun und nichts mit OS X-Treibern für HFS+-Platten.

Edit: "Erste Hilfe" hieß im Original "Disk First Aid", falls sich noch jemand erinnert. Ja, das waren noch Zeiten als ich 1991/1992 meinen ersten Mac bekam: Ein seeliger //ci mit Motorola 68030 auf 25 Mhz. Und die "Erste Hilfe" auf einer niedlichen Notfall-Diskette. Hach, schön war das damals. Ja, damals vor 16 Jahren, da hatte Defragmentierung noch einen Sinn. Schick mit den Norton Utilities ging das. Ja ja, die Jugend, sie kehrt nicht wieder.

Alles klar...

Mist, muss ich doch echt meine Rechner bzw BetriebssystemScheiben reklamieren...

Willst Du nicht lieber mal bissl an Deiner Website weiterarbeiten...?

weitermachen.

 

[MacMark]

Alles klar...

Reiterbeschriftung ungleich Programm-Name. Falls Dir das nicht genügt, sollte Dir mindestens auffallen, daß in dem Artikel von MacOS und nicht von OS X die Rede ist.
Aber Bildschirmphotos kannst Du schon gut. Welche Kamera hast Du?

 

[lundehundt]

im original US System heisst Erste Hilfe schon immer Disk Utility und das kbase Dokument habe ich zitiert um etwas ueber HFS und HFS+ File Systeme deutlich zu machen. An diesem File System hat sich unter OS X nichts gaendert. Von daher ist es voellig unerheblich, ob HFS+ bereits unter OS 8 und 9 verfuegbar war.

Es ging in meinem Beitrag darum was Diskwarrior unternimmt um optimierter auf das File System (HFS+) zuzugreifen

Deine Ueberheblichkeit steht in keinem Verhaeltnis zu deiner Bereitschaft, dich auf eine Sachdiskussion einzulassen.

 

[MacMark]

im original US System heisst Erste Hilfe schon immer Disk Utility …

Falsch, denn es hieß "Disk First Aid" bei MacOS 7/8/9. Das "Disk Utility.app" gab es erst mit OS X. Deine Verbesserungsvorschläge stehen im Verhältnis zu Deinem Wissen

Edit: Bitteschön der US-Link:
http://download.info.apple.com/Appl..._American/Macintosh/Utilities/Disk_First_Aid/

 

[lundehundt]

bis 2002 hiess es so - und du hast gewonnen

 

[MacMark]

bis 2002 hiess es so …

Nein es ist nicht nur der Name unterschiedlich, sondern die Programme selbst, denn "Disk First Aid" und "Disk Utility.app" sind verschiedene Programme für verschiedene Betriebsysteme.

Wenn Du die Infos zu "Disk Utility.app" bemühst, siehst Du dort ein Copyright von Apple aus dem Jahre 1999. Zuvor kannte man es unter "/etc/disk utility" in NEXTSTEP.

Bitte versuch erst wieder witzig zu sein, wenn die Lacher nicht nach hinten losgehen

 

[lundehundt]

wieder nein Disk first Aid ist unter Mac OS ein eigenstaendiges Programm - unter OS X ist es Bestandteil des Disk Utilities

First Aid is a utility included in Mac OS and Mac OS X for checking and repairing file system errors. In Mac OS 9 and earlier, it is a separate program called Disk First Aid; in Mac OS X, it is part of the Disk Utility program.

http://kb.iu.edu/data/adhu.html

Und genau darum ging es: um HFS+ und das Tool das das File System unter OS X und OS9 und frueher repariert (Disk First Aid)

Aber gewonnen hast du trotzdem...

 

[MacMark]

… HFS+ und das Tool das das File System unter OS X und OS9 und frueher repariert (Disk First Aid) …

Die Fragmentierungsprobleme waren unter MacOS 7/8/9 eine völlig andere Geschichte als unter OS X. Dort gravierend, hier nahezu bedeutungslos.

 

[lundehundt]

es geht in dem Beitrag in dem das kbase doc verlinkt ist nicht um Fragmentierung sondern darum was Diskwarrior macht um die Zugriffe auf das File System zu optimieren. Aber das habe ich schon mehrfach erwaehnt. Ich habe auch mehrfach erwaehnt, dass wir uns darin einig sind, dass OS X bei files <20MB die Fragmentierung sehr gut im Griff hat.

Ich habe noch nicht erwaehnt, dass eine geringe Fragmentierung von Files unter OS X zu Lasten einer starken Fragmentierung des freien Speicherplatzes verwirklicht wird. Du kannst ja mal die freeware ShowVolumeFrag laufen lassen. Die zeigt dir im Detail die Groesse der freien Speichersektoren eines Volumes die physikalisch zusammenhaengen. Ich benutze iDefrag auf Volumes auf die ich staendig multi-media Dateien speichere, veraendere und loesche, die in der Regel >20MB sind. Und da macht es absolut Sinn das zu tun.

 

[lundehundt]

Die Fragmentierungsprobleme waren unter MacOS 7/8/9 eine völlig andere Geschichte als unter OS X. Dort gravierend, hier nahezu bedeutungslos.

Um zum Ausgangspunkt zurueck zu kehren: wenn es, wie du behauptest, ueberhaupt keine Rolle spielt was das File System ueber die Fragmentierung zu wissen scheint und was nach dem mapping durch die Firmware der Platte tatsaechlich fragmentiert wird, wie kannst du dann den Aussagen ueber die geringe Fragmentierung von OS X glauben? Die Leute die diese Aussage getroffen haben, koennen es doch auch nicht wissen, sondern nur dann, wenn sie detailierte Kenntnis ueber das jeweilige mapping Verfahren der unterschiedlichen Festplattenhersteller haetten.

 

[IceHouse]

[...]Heißt: Wenn der Job verpennt wurde, wird er beim Aufwachen nachgeholt. Wird ein Job mehrfach verschlafen, wir er nur einmal nachgeholt.[...]

Da bin ich ja mal froh, das ich seit 2002 den anacron nutze um diesen ganzen "crontab" Kram zuverlaessig abarbeiten zu lassen. Einmal eingerichtet, updates gemacht und mal einen Eintrag hinzugefuegt. Nicht mehr und nicht weniger. Er hat mich nie im Stich gelassen. Das verstehe ich unter "Automatismus".

--($:~)-- fink info anacron
Information about 6674 packages read in 1 seconds.

anacron-2.3-6: Periodic command scheduler
 Anacron executes commands at intervals specified in days
 Unlike cron, it does not assume that the system is running continuously.
 It's ideal for machines such as laptops
 .
 Usage Notes:
 It is very important that you read the README files in the docs folder 
 if you plan to add any scheduled tasks. Note that the anacrontab file format
 is different from that used in the standard crontab. Consult the manual page
 for anacrontab.5 for details.
 .
 Fink Developer Note: 
 If your package requires some sort of recurring activity, you can add a
 script to the <fink prefix>/etc/cron.{daily,weekly,monthly} directory. 
 See the run-parts(8) manpage for the structure of these scripts.
 .
 Web site: http://sourceforge.net/projects/anacron
 .
 Maintainer: Christian Swinehart <cswinehart@users.sourceforge.net>

Gruss von IceHouse

 

[MacMark]

wieder nein Disk first Aid ist unter Mac OS ein eigenstaendiges Programm - unter OS X ist es Bestandteil des Disk Utilities …

Bestandteil von? Marketinggewäsch, um den Usern den Übergang zu erleichtern. Zeig mir doch einmal "Repair Disk Permissions" im "Disk First Aid". Oder irgendeine Zeile gemeinsamen Code.

 

[MacMark]

… anacron nutze um diesen ganzen "crontab" Kram zuverlaessig abarbeiten zu lassen …

Anacron habe ich auch empfohlen …
http://www.macmark.de/osx_auto-clean.php
… bis es launchd gab und die crontab eine leere Ruine wurde. Schau doch mal rein

"crontab: no crontab for root"

 

[lundehundt]

Bestandteil von? Marketinggewäsch, um den Usern den Übergang zu erleichtern. Zeig mir doch einmal "Repair Disk Permissions" im "Disk First Aid". Oder irgendeine Zeile gemeinsamen Code.

Disk First Aid dient der Pflege eines korrupten HFS bzw HFS+ File Systems. Das war unter OS 9 und < seine einzige Aufgabe und es war ein eigenstaendiges Programm. Disk First Aid ist unter OS X Bestandteil der Disk Utilities die neben dem Reaprieren korrupter File Systeme (Volume reparieren) noch eine Vielzahl anderer Aufgaben unter seinem Dach vereint. Z.b. das abgleichen und reparieren der Default Rechte des Systems und seiner Bestandteile mit dem Ist-Zustand der Rechte im File System. Oder das Erzeugen von Disk Images, das formatieren und Partitionieren von Festplatten mit unterschiedlichen File Systemen usw.

Die verlinkte Seite stammt von einer Universitaet und ist kein Marketing Gewaesch. Und HFS+ ist ein File System das unter OS 9 und < und OS X eingesetzt wird. Von daher ist die Struktur des File Systems so wie sie in dem kbase dokument dargestellt wird, auch gleich. Ob das Programm das selbe ist spielt doch gar keine Rolle - das File System ist es.

 

[MacMark]

Um zum Ausgangspunkt zurueck zu kehren: wenn es, wie du behauptest, ueberhaupt keine Rolle spielt was das File System ueber die Fragmentierung zu wissen scheint …

Es gibt Fragmentierung auf verschiedenen Ebenen: Physikalisch (kennt nur die Platte), logisch (sieht man durch die Mapping-Brille) und der Verzeichnisbaum selbst kann auch noch aufgebläht sein. Defragmentierungstools beschäftigen sich mit dem, was sie durch das Mapping sehen und eher selten mit dem Verzeichnisbaum, was auf OS X mehr bringen würde. Eine effiziente Verzeichnisstruktur bekommt man ganz einfach mit Formatieren und Zurückkopieren hin. Bringt aber nur etwas, wenn man viele Dateien nutzt (Millionen). Leute mit wenigen aber großen Dateien profitieren davon kaum.

… Ob das Programm das selbe ist spielt doch gar keine Rolle - das File System ist es.

Word und OpenOffice-Writer haben auch nicht den gleichen Code, obwohl sie auf Worddateien operieren können. Nicht jedes Programm, was auf HFS+ rumfummeln kann, ist das gleiche.

Ich muß mich wohl noch einmal wiederholen: Das Dateisystem alleine ist piepegal, wenn man nicht die Treiber des Betriebssystems in die Betrachtung einbezieht. Nur Dateisystem und Treiber zusammen zu betrachten ergibt einen Sinn, wenn man über Fragmentierung redet. Das gleiche Dateisystem unter einem anderen Betriebssystem mit anderen Treibern weist ein völlig anderes Fragmentierungsverhalten auf. Darum sind sämtliche Links die HFS+ unter dem Aspekt "MacOS" behandeln vollkommen schnurz, da MacOS und Mac OS X völlig unterschiedliche Treiber für HFS+ nutzen.

 

[lundehundt]

Es gibt Fragmentierung auf verschiedenen Ebenenhysikalisch (kennt nur die Platte), logisch (sieht man durch die Mapping-Brille)

Welchen Grund gibt es logisch zu fragmentieren wenn das physikalisch nicht noetig ist. Fragmentierte Dateien - ob logisch oder physikalisch - verlangsamen den Zugriff. Das ergibt sich aus der Struktur des File Systems (Extents Trees von HFS+)

Eine effiziente Verzeichnisstruktur bekommt man ganz einfach mit Formatieren und Zurückkopieren hin.

Das sorgt eher fuer eine defragmentierung vorher fragmentierter Dateien.

Bringt aber nur etwas, wenn man viele Dateien nutzt (Millionen). Leute mit wenigen aber großen Dateien profitieren davon kaum.

Ich dachte hot file clustering und die 7-Extents Regel verhindert gerade das fragmentieren von kleinen Dateien und auf groessere Dateien wird das nicht angewendet (>20MB)

Ich muß mich wohl noch einmal wiederholen: Das Dateisystem alleine ist piepegal, wenn man nicht die Treiber des Betriebssystems in die Betrachtung einbezieht.

Du musst das nicht wiederholen. Ein File System ist ein File System und hat nichts mit Festplattentreibern zu tun. Die schematischen Darstellungen wie die Struktur von HFS+ aufgebaut ist (in dem verlinkten kbase doc) entspricht der von heute.

 

[MacMark]

… das fragmentieren von kleinen Dateien …

Ich sprach in diesem Punkt nicht von fragmentierten Dateien, sondern vom Verzeichnisbaum, welcher eher bei vielen kleinen Dateien suboptimal werden kann als bei wenigen großen.

… hot file clustering …

Manuelle Defragmentierung schadet dem hotfile clustering. Und das hotfile clustering schadet manueller Defragmentierung. Das hotfile clustering verträgt sich jedoch mit OS X eigenen Defragmentierungsroutinen.

… Ein File System ist ein File System und hat nichts mit Festplattentreibern zu tun. …

Ein Filesystem fragmentiert abhängig vom verwendeten Betriebssytem und dessen Festplatten-Treibern unterschiedlich.

 

[lundehundt]

ich mag nicht mehr laenger an dir vorbei reden solange ich keine Antwort auf die wichtigste Frage bekomme

Es gibt Fragmentierung auf verschiedenen Ebenenhysikalisch (kennt nur die Platte), logisch (sieht man durch die Mapping-Brille)

darauf meine Frage:

Welchen Grund gibt es logisch zu fragmentieren wenn das physikalisch nicht noetig ist. Fragmentierte Dateien - ob logisch oder physikalisch - verlangsamen den Zugriff. Das ergibt sich aus der Struktur des File Systems (Extents Trees von HFS+)

Ein Filesystem fragmentiert abhängig vom verwendeten Betriebssytem und dessen Festplatten-Treibern unterschiedlich.

Voellig richtig - allerdings geht es in dem verlinkten kbase Dokument um die Struktur von HFS+ und was Diskwarrior tut um die zu optimieren. Diese Struktur ist die von HFS+ und ist unter OS 9 und < die gleiche wie unter OS X (das meine ich mit: aneinander vorbei reden)

............................ |
Partitionsinformationen . |
............................ --------
Festplattentreiber-Partition
............................ --------
Boot-Blöcke (Startblöcke) . |
............................ |
Master Directory Block(MDB). Macintosh Partition
............................ |
Volume Bitmap . |
............................ |
Katalog . |
............................ |
Extents Overflow File . |
............................ |
Dateien/Freier Platz . |
............................ |
Alternativer MDB . |
............................ -------
............................ Andere Partitionen
............................ -------

(Byte) Data Fork

0..............................
Node 0 . Header Node
512............................
Node 1 ._____________________
1024........................... |
Node 2 . Node Substructure |
n.............................. |
Node 3 . |
............................... .......................
. . Node Descriptor .
. .......................
. ---. Record 0 .
. | .......................
. | . Free Space .
. | .......................
. | . Offset to Free Space.
. | .......................
. | . Offset to Record 0 .
Node n/512 | .......................
|
..........................................................
. Key | Record Key | Record Data oder Pointer .
. Length | | .
. Value | | .
. (255 byte) | | .
..........................................................


Nachfolgend sehen Sie ein Beispiel für eine B-Baum-Struktur:

Header Node |Pointer1|Pointer2|Pointer3|
|
|
Index Nodes |Pointer26|Pointer2|Pointer41|
|
|
Leaf Nodes |(13) Data|(2) Data|(16) Data|

Manuelle Defragmentierung schadet dem hotfile clustering. Und das hotfile clustering schadet manueller Defragmentierung. Das hotfile clustering verträgt sich jedoch mit OS X eigenen Defragmentierungsroutinen.

Programme wie iDefrag lassen den Hot-File Cluster voellig unangetastet. Diese 5 GB reservierter Platz im physikalisch schnellsten Zugriffsbereiche der Platte der fuer kleine Systemdateien benutz wird die nur gelesen werden, bleibt voellig unangetastet.

Ich sprach in diesem Punkt nicht von fragmentierten Dateien, sondern vom Verzeichnisbaum, welcher eher bei vielen kleinen Dateien suboptimal werden kann als bei wenigen großen.

Das ist sicher richtig. Allerdings kommt die groesste Zugriffsbremse meiner Meinung auch hier aus den extents (Sprungadressen von Dateifragmenten) da an vielen verschiedenen Stellen im Verzeichnisbaum gelesen werden muss (siehe oben) um die Addressen und dann die Fragmente einer Datei als ganzes in's RAM zu laden.

Ein "Extent" ist ein zusammenhängender Speicherbereich aus logischen Blöcken, der einer Datei zugeordnet ist. In der "Extents"-Datei (auch "Extents Overflow File" genannt) werden die Speicherpositionen von Datensätzen protokolliert, die nicht zusammenhängend gespeichert werden können. Diese Informationen werden verwendet, um beim Laden einer Datei die an verschiedenen Positionen gespeicherten Teile der Datei wiederzufinden. Einige "Extent"-Informationen befinden sich auch im MDB und im VCB. Die ersten drei Extents bleiben immer zusammen mit dem VCB im Speicher.

 

[MacMark]

Ich habe die Kernpunkte der beiden relevanten Quellen (Praxistest und Beschreibung von Amit Singh sowie Apples Artikel über Fragmentierung mit OS X) auf deutsch übersetzt und bei mir aufgenommen:
http://www.macmark.de/osx_auto-clean.php#defragmenting

 

[magheinz]

Hier mal der relevante Teil der Antwort von hitachi:

Die Sektoren, welche das Betriebssystem erkennt, unterscheiden sich von den
Sektoren der Festplatte. Das Betriebssystem erkennt nur die angegebene
Groesse der Festplatte und dadurch auch die anhand der Groesse angegebenen
Sektoren. Jedoch befinden sich darueber hinaus noch Ersatzsektoren auf der
Festplatte.

Ich denke das ist eine belastbare Quelle für die These der "logischen Sicht". Auch wenn es keine Aussage ist wie weit diese sich von der Physikalischen unterscheidet, so ist doch eindeutig DAS se sich unterscheidet.

Übrigens:

# hdparm /dev/sda
/dev/sda:
 IO_support   =  0 (default 16-bit)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 7296/255/63, sectors = 117210240, start = 0

# fdisk -l /dev/sda

Platte /dev/sda: 60.0 GByte, 60011642880 Byte
255 Köpfe, 63 Sektoren/Spuren, 7296 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes

Das kann nicht sein, 255 Köpfe in einer 1,8"-Platte?
Das sind definitiv fiktive Werte die die firmware vorgaukelt.