Belanglosigkeiten aus meinem Leben
Michael M. aus Berlin kenne ich zwar gar nicht, ihm habe ich aber zu verdanken, dass ich heute völlig unerwartet Post von Amazon bekommen habe. Ein kleines Päckchen mit einem Geschenk lag morgens auf der Treppe:
Ich weiß zwar nicht, warum ich das verdient habe (obwohl ich eine Vermutung habe), aber ich habe mich jedenfalls sehr gefreut. Dankeschön!
Ab dem kommenden Semester gibt es an der TU Dortmund neue Semestertickets. Während die alten aus rosa Zettelchen in Kreditkartenformat bestanden, auf die einfach „Freie Fahrt in allen VRR-Verkehrsmitteln und H-Bahn“ gedruckt war, und damit sowas von fälschbar waren, ist das neue Ticket wesentlich fälschungssicherer.
Schon etwas zu übertrieben fälschungssicher. Das Ding ist total überladen mit Zahlen und Symbolen, Barcodes, doppelten Beschriftungen und winzig kleinen Details. Sogar der graue Rand gehört angeblich zu den Sicherheitsmerkmalen. Unsere Euro-Scheine sind nichts dagegen.
Ironischerweise bekommt jeder Student das Ticket als PDF-Datei. Zum selbst ausdrucken. Mit dem Hinweis, dass man die Größe nicht verändern dürfe. Das PDF-Dokument kommt noch dazu im Nicht-DIN-Format US-Letter. So viel dazu.
Am besten ist aber das wirklich handliche Format des ausgeschnittenen Tickets von 17,5 cm x 11,3 cm. Passt in jedes Portemonnaie, kann man schnell vorzeigen. Einfach praktisch.
Semesterticket (oben), Führerschein zum Vergleich (unten)
Wer denkt sich eigentlich einen derart praxisfremden Blödsinn aus?
(Dieser Artikel ist auch auf deutsch verfügbar.)
This article refers to a predecessor article concerning Time Machine backups on network shares in Leopard.
In the comments on this article a thread in Apple’s support forums was mentioned which describes problems with Time Machine and network shares (thanks to John M for that remark).
To explain the problem you need to be aware of how sparse bundle images (the ones Time Machine uses for network backups) work. Sparse bundle images and sparse images are special forms of disk images with certain advantages. To say it in simple terms a disk image is just a file that is treated like a drive (e. g. a hard disk). The image file is contained in a real drive (locally or on the network) which I will call container.
You can mount the image and use it like a real drive. Mac OS X takes care of writing the data into the image file. In the simplest case the image is a file that has exactly the size of the virtual drive’s maximum capacity. If you create an image with 100 GB capacity you will have a 100 GB file even if the image only contains some MB of data.
And here the sparse images come into play. They occupy only the space the data in the image occupies. Therefore, you can create an image with 100 GB capacity which as a file is only a few MB big. The image file grows as it is filled with data.
However, there is a catch in it. Deleting files in the image does not result in a smaller image file. For example: If you create a 10 GB file in the image the image file will increase to a size of 10 GB as well. Free space in the image will be 90 GB. Afterwards you delete the file and the free space in the image will be 100 GB again. Without further intervention the image file however will keep its size of 10 GB*. Inside the image everything is in order. Thus, while using the image its file will at most keep its size, mostly grow in size (due to creating further files in the image), but never shrink by itself. This is one part of the problem.
The other part of the problem is a behaviour of Mac OS X which is actually really useful. Mac OS X does not prevent the user from creating a sparse image with a maximum capacity bigger than the free space or even the maximum capacity of the container. This may turn out to be a problem. For example take our fresh image with 100 GB capacity. Assume its in a container with 20 GB free space. The user might want to create a 30 GB file in the image which naturally will not work.
Mac OS X acts rather clever here. If an image is mounted Mac OS X checks how much free space is available in the container (here 20 GB). If this value is smaller than the theoretically free space in the image (here approx. 100 GB) Mac OS X will limit the free space in the image to the free space of the container. In our example: The image has a maximum capacity of 100 GB and 20 GB free space even if there are no files on the image!
In itself this behaviour makes sense. In combination with Time Machine it can lead to fatal consequences. For example: In our previously mentioned image you create an 18 GB file. The image file will grow to a size of 18 GB. Afterwards free space in the container and the image will be 2 GB. Now you delete the 18 GB file. Theoretically the free space in the image will increase by 18 GB.
Now both above mentioned effects come into play. The image file will keep its size of approx. 18 GB. Hence the free space in the container will still be 2 GB. Therefore, the free size in the image will as well be only 2 GB. In this case deleting a file in the image does not create further free space in it. If you want to create a new 18 GB file Mac OS X will not allow that. The problem can be avoided by always keeping enough free space in the container. In our case we would have to free at least 16 GB in the container*.
Assume in our initial situation above free space in the container would not be 20 GB but 120 GB. Mac OS X will then always specify the free space regarding only the image (100 GB capacity). Deleting the 18 GB file will indeed increase the free space to 100 GB. This also shows how fatal it is, if the maximum capacity (or the maximum free space respectively) of the container is less than the capacity of the image. In this case the free space of the image will always be specified regarding the container. At some point the image will become unusable because the image file grows inexorably while the apparent free space of the image shrinks.
This is exactly the trap Time Machine falls into, if you do not pay attention to the free space on the network drive. Assume the Time Machine image has less free space than the next backup needs. Time Machine will then automatically delete old backups to free up some additional space. If the free space on the network share is greater than that in the image (i. e. the free space in the image is not affected by the free space in the container) everything will work smoothly. With every deleted old backup the free size in the image will grow a little.
However, if the free size in the image is limited by the container deleting backups will not create additional free space. Time Machine will futilely keep on deleting all backups but the last one in order to clear space. Afterwards it will fail due to lack of free space (like in the above mentioned support thread).
Possible trouble-shootings:
Disclaimer: I have never experienced these problems in Time Machine myself. Therefore, I cannot guarantee that the above stated solutions actually work. In my case there is enough free space on the network share so that backups are created smoothly. Your own reports and experiences are very appreciated.
You should always be aware that Time Machine backups on network shares are not officially supported by Mac OS X (except Time Capsule). In doubt you should not trust a solution like this.
* There is a possibility to reclaim unoccupied space via hdiutil. However, as Time Machine does not utilize it I will ignore this possibility here.
(This article is also available in English.)
Dieser Artikel bezieht sich auf einen Vorgängerartikel zum Thema Time-Machine-Backups auf Netzwerkfreigaben unter Leopard.
Aus den Kommentaren in der englischen Version des ersten Artikels kam ein Hinweis auf einen Thread in Apples Supportforen, der auf ein Problem mit Time Machine und Netzwerkfreigaben hinweist (Danke an John M dafür).
Um das Problem zu erklären muss man sich jedoch erst klar machen, wie Bundle-Images (die Time Machine für Netzwerk-Backups verwendet) funktionieren. Sparse-Bundle-Images („mitwachsendes Bundle-Image“) und Sparse-Images („mitwachsendes Image“) sind spezielle Formen eines Disk-Images mit bestimmten Vorteilen. Ein Disk-Image ist vereinfacht gesagt nur eine Datei, die wie ein Laufwerk (z. B. eine Festplatte) behandelt wird. Die Image-Datei liegt auf einem echten Laufwerk (lokal oder im Netz), dass ich als Container bezeichnen werde.
Das Image kann man ins System einbinden („mounten“) und dann wie ein Laufwerk verwenden. Mac OS X kümmert sich darum, die Daten in die Image-Datei zu schreiben. Prinzipiell ist ein Image also im einfachsten Fall eine Datei, die genauso groß ist, wie die Maximalgröße des virtuellen Laufwerks. Erstellt man also ein Disk Image mit 100 GB Kapazität, hat man eine 100 GB große Datei, selbst wenn im Image nur wenige MB belegt sind.
Und hier kommen die Sparse-Images ins Spiel. Diese belegen nur den Platz, den auch die Daten im Image belegen. Man kann also ein Image mit 100 GB Kapazität erstellen, das als Datei nur wenige MB groß ist. Erst wenn das Image mit Daten gefüllt wird, wächst auch die Image-Datei.
Allerdings hat die Sache einen Haken. Das Löschen von Daten im Image sorgt nicht dafür, dass die Image-Datei kleiner wird. Anschaulich: Erstelle ich im Image eine 10 GB große Datei, wird die Image-Datei 10 GB groß, der freie Speicher im Image beträgt 90 GB. Lösche ich die Datei anschließend, sind im Image wieder die kompletten 100 GB frei. Die Image-Datei selber behält aber ohne Weiteres ihre Größe von 10 GB*. Innerhalb des Images ist also alles in Ordnung. Durch Benutzung des Images wird die dazugehörige Datei selbst höchstens gleich groß bleiben, meistens wachsen (indem weitere Dateien im Image erstellt werden), aber von alleine nie kleiner werden. Dies ist ein Teil des Problems.
Der andere Teil liegt in einem Verhalten vom Mac OS X, das sonst eigentlich sehr nützlich ist. Mac OS X hindert den Nutzer nicht, ein Sparse-Image zu erstellen, dessen Maximalkapazität den freien Platz oder gar die Maximalkapazität des Containers überschreitet. Prinzipiell ist das natürlich ein Problem. Nehmen wir unser frisches Image mit 100 GB Kapazität. Dieses liege in einem Container mit 20 GB freiem Speicher. Im Image könnte der Benutzer nun eine 30 GB große Datei erstellen wollen, was natürlich nicht funktionieren kann.
Hier verhält sich Mac OS X vergleichsweise schlau. Wird ein Image gemountet, prüft Mac OS X wie viel Platz im Container frei ist (hier 20 GB). Ist dieser Wert kleiner als der formal freie Platz im Image (hier ca. 100 GB), so wird Mac OS X den freien Speicher im Image auf den freien Speicher im Container begrenzen. In unserem Beispiel: Das Image hätte eine Maximalkapazität von 100 GB und 20 GB freien Speicher. Und das, obwohl auf dem Image noch gar keine Daten liegen!
An sich ist dieses Verhalten sinnvoll, im Zusammenspiel mit Time Machine jedoch kann es fatale Folgen haben. Angenommen wir erstellen im obigen Image eine 18 GB große Datei. Die Image-Datei wird auf 18 GB anwachsen, im Container wie auch im Image sind anschließend nur noch 2 GB frei. Jetzt löschen wir die 18 GB große Datei wieder. Im Image werden dadurch formal 18 GB frei.
Aber nun kommen die beiden obigen Effekte ins Spiel. Die Image-Datei wird ihre Größe von ca. 18 GB behalten. Im Container sind daher nur 2 GB frei. Also sind auch im Image nur 2 GB frei. Das Löschen der Datei im Image hat also keinen zusätzlichen Platz geschaffen. Möchten wir nun erneut eine 18 GB große Datei erstellen, wird Mac OS X dies nicht erlauben. Umgehen lässt sich das Problem, wenn im Container immer genug freier Speicher verfügbar ist. In unserem Fall müssten wir also dort mindestens 16 GB frei machen*.
Haben wir in der obigen Ausgangssituation im Container nicht 20 GB sondern 120 GB frei, wird sich Mac OS X beim freien Speicher immer am Image orientieren. Das Löschen der 18 GB großen Datei wird also tatsächlich dazu führen, dass im Image wieder 100 GB Speicher frei werden. Hier zeigt sich auch, wie fatal es ist, wenn die Maximalkapazität (bzw. der maximale freie Speicher) des Containers kleiner als die Kapazität des Images ist. In diesem Fall wird sich der freie Speicher immer am Container orientieren. Das Image wird irgendwann unbrauchbar, weil die Image-Datei immer weiter anwächst und damit der scheinbar freie Speicher im Image immer kleiner wird.
In genau diese Falle tappt Time Machine, wenn man beim freien Speicher auf dem Netzlaufwerk nicht aufpasst. Angenommen im Time-Machine-Image ist weniger Platz verfügbar als Time Machine für das nächste Backup benötigt. Time Machine wird dann automatisch alte Backups löschen, um zusätzlichen Platz zu schaffen. Ist auf dem Netzlaufwerk mehr freier Speicher verfügbar als im Image (d.h. ist der freie Speicher im Image nicht vom Container betroffen), läuft alles problemlos. Durch jedes gelöschte alte Backup wird im Image etwas mehr Speicher frei.
Ist aber der freie Speicher im Image durch den Container begrenzt, wird das Löschen eines Backups keinen zusätzlichen Speicher verfügbar machen. Time Machine wird dann alle Backups bis auf das letzte löschen und anschließend das Backup wegen Speichermangel abbrechen (wie im o. g. Apple-Support-Thread).
Mögliche Lösungen für dieses Problem:
Disclaimer: Ich selber habe diese Probleme nie im Zusammenhang mit Time Machine erlebt und kann daher auch nicht garantieren, dass obige Lösungen wirklich funktionieren. Hier ist momentan genug Speicher auf der Netzfreigabe verfügbar, so dass Backups problemlos erstellt werden. Für Praxisberichte und Erfahrungen wäre ich dankbar.
Man sollte sich auch dessen bewusst sein, dass Time Machine Backups auf Netzwerkfreigaben (Time Capsule ausgenommen) nicht von Mac OS X unterstützt werden. Im Zweifel sollte man einer solchen Lösung also nicht vertrauen.
* Es gibt auch die Möglichkeit, per hdiutil den unbelegten Speicher wieder freizugeben. Diese Möglichkeit nutzt Time Machine (um die es hier geht) jedoch nicht von alleine, weswegen ich diese Möglichkeit außen vor lasse.
Seitdem auf meinem Notebook Mac OS X Leopard (10.5) läuft, habe ich einen neuen Lieblingsbrowser. Nachdem ich mich immer mehr geärgert hatte, hab ich mich endlich vom Firefox getrennt. Die Gründe dafür sind vielfältig, kann ich bei Interesse gerne erläutern, gehören aber jetzt nicht hier her.
Safari hat in der aktuellen Version 3 endlich Features bekommen, die bisher den Wechsel von Firefox ausschlossen. Aber inzwischen kann Safari mehrere Tabs als Bookmarks speichern, im Gegensatz zu Firefox nach dem Beenden komplette Sessions zuverlässig wiederherstellen und für mich am wichtigsten den Benutzer warnen, wenn er (womöglich ausversehen) ein Fenster mit mehreren Tabs schließen will. Letzteres ist eine totale Kleinigkeit, für mich aber eine essentielle Funktion, ohne die ich mich schon mehrfach extrem aufgeregt hätte (ich habe oft 10-30 Tabs in einem Fenster offen, da ist das extrem blöd, wenn das alles weg ist).
Johnny hat sich drüben bei MobileMacs mal über Bediener-Ärgernisse bei Apple aufgeregt. Während ich das dort aber eher als ärgerliche Kleinigkeiten abtun würde, macht Safari bzw. Mac OS X generell etwas wirklich total Unsinniges.
Drückt man Command-W, schließt Safari den aktuellen Tab. Command-Shift-W schließt das gesamte Fenster, ggf. mit Nachfrage. Und wenn man einmal abrutscht, und Command-Alt-W in einem Fenster ohne Tabs drückt? Dann schließt Safari bzw. Mac OS alle offenen Fenster von Safari. Ohne Nachfrage.*
Größere Recherche gemacht? Pech gehabt. Gerade in einem weiteren Fenster eine E-Mail im Webmailer angefangen? Pech gehabt. Ausversehen die falsche Taste gedrückt? Pech gehabt.
Glücklicherweise konnte ich Quicksilver dazu überreden, Command-Alt-W systemweit abzufangen. Drücke ich diese Kombination, passiert Folgendes:
Damit ich mich dann auch immer wieder an diese Bedienfreundlichkeit erinnern darf.
* Drückt man Command-Alt-W in einem Fenster mit Tabs, schließt Safari nur alle Tabs in dem Fenster, auch ohne Nachfrage. Zur Konsistenz dieser Bedienung muss man nichts sagen, oder?
Angeblich will der Provider Versatel durch seinen Investor den Provider QSC kaufen. Das wäre an sich im deutschen Kommunikationsmarkt bzw. in der Wirtschaft allgemein nichts besonderes. Konsolidierung nennt Heise das. Verfestigung also, klingt irgendwie positiv.
Man könnte diese Meldung also getrost ignorieren. Interessant wird es aber, wenn man sich ansieht, wo QSC und Versatel im Kommunikationsmarkt stehen. QSC konzentriert sich eher auf Großkunden, während Versatel für günstige billige Breitbandanschlüsse in Privathaushalten bekannt ist.
Der Knackpunkt, wo hier Welten aufeinander krachen, liegt aber anderswo. Während QSC für seine gute Kundenbetreuung bekannt ist und damit sicher zu den Providern mit dem besten Support überhaupt gehört, kann man Versatel ohne Zweifel das Gegenteil attestieren.
Ich kenne buchstäblich niemanden, der bei Versatel Kunde ist und nicht zumindest schon einmal kleinere Probleme hatte. Die schlimmeren Fälle (die ich zum Glück nur aus Fachzeitschriften kenne) reichen bis hin zu Providerwechseln, bei denen Kunden monatelang ohne Internet und sogar Festnetz auskommen müssen. Aber auch in meinem direkten Bekanntenkreis habe ich schon oft meine Vorurteile gegen Versatel bestätigen müssen.
Bei QSC hingegen sind mir keine Negativfälle bekannt. Sicher muss man hier berücksichtigen, dass QSC gerade im Privatkundengeschäft viel weniger Kunden hat. Ich kann aber aus eigener Erfahrung berichten. Seit 4,5 Jahren sind wir Kunde der Privatkundentochter Q-DSL home. In dieser Zeit fiel das Internet zwei Mal für jeweils zwei Tage aus, weil das Modem defekt war und wir auf ein neues warten mussten (welches QSC selbstverständlich kostenfrei zum Kunden schickt). Weitere Ausfälle gab es nicht. Das entspricht einer Verfügbarkeit von 99,76%.
Wenn bei QSC Wartungsarbeiten anstehen, werden diese in der Regel Montags morgens zwischen 0:00 Uhr und 6:00 Uhr erledigt. Man erhält zwei Wochen vorher eine Benachrichtigung über den zu erwartenden Ausfall, auch wenn dieser nur 15 Minuten dauern soll. Zumindest bei der Telekom weiß ich, dass hier gerne mal tagsüber am Werktag Leitungen ausfallen und man dann erst auf Nachfrage erfährt, dass man von Bauarbeiten betroffen ist.
Und auch sonst kann ich vom QSC-Support nur Positives berichten. Der Support ist über richtige E-Mail-Adressen erreichbar und antwortet auch persönlich und schnell (teilweise per Telefon). Die Hotline kann man für günstige 4 Cent/Min. anrufen. Lange Warteschleifen habe ich dort nie erlebt. Dauert der Support länger, muss man nicht in der Hotline warten, sondern wird anschließend zurück gerufen.
Und schließlich existiert noch ein privates Q-DSL-Supportforum, in dem einige QSC-Supportmitarbeiter freiwillig mitlesen und sich um Probleme und Störungen in der Regel sehr schnell kümmern.
Wenn nun also Versatel QSC schluckt, dann kann das für QSC, dessen Support und die Kunden nichts Gutes heißen. Bleibt zu hoffen, dass von der exzellenten Kundenbetreuung nicht zu viel weg gespart und ausgegliedert wird.
Aktuelle Kommentare