Zusammenspiel von aktuellen/künftigen Speichertechnologien und Dateisystemen
Aus Winfwiki
1 Abbildungsverzeichnis
| Abb.-Nr. | Abbildung |
|---|---|
| 1 | Schematischer Aufbau einer P-ATA Schnittstelle |
| 2 | Schematischer Aufbau einer S-ATA Schnittstelle |
| 3 | DVD - Dual Layer |
| 4 | HVD Laufwerk und Medium: tapestry 300r |
| 5 | Zwei-Achsen und Collinear Technik von Optware |
| 6 | HVD Disc Struktur |
| 7 | Schematischer Aufbau einer Hybrid Solid State Disk |
| 8 | ZFS - Hybrid Storage Pools |
| 9 | Schematischer Aufbau eines NTFS-formatierten Datenträgers |
| 10 | Schematischer Aufbau der TrueFFS Partition |
| 11 | Zwei-Tier Architektur mit SSDs und magnetischen Festplatten |
2 Tabellenverzeichnis
| Tabelle Nr. | Titel |
|---|---|
| 1 | Vergleich Wellenlänge des Lasers bei CD und DVD |
| 2 | Gegenüberstellung HVD und tapestry |
| 3 | Bitzustände bei Schreiboperationen auf NAND-Flash Speicher |
| 4 | Beispiele von wichtigen Performancewerten in Abhängigkeit zur Einsatzbereich des Dateisystems |
| 5 | Betriebssicherheit: Techniken und Konzepte |
| 6 | Zugriffsbeschränkung: Techniken und Konzepte |
| 7 | Übersicht über Revisionen von UDF |
| 8 | Grundanforderungen des E-Mail- und E-Mailarchivsystems |
| 9 | Fallstudie 1: Lösungsmöglichkeiten/Konfigurationen |
| 10 | Fallstudie 1: Kosten Serversysteme |
| 11 | Fallstudie 1: Kostenvergleichsrechnung zu Architektur 1: Externer Speicher, Variante 1 |
| 12 | Fallstudie 1: Kostenvergleichsrechnung zu Architektur 1: Externer Speicher, Variante 2 |
| 13 | Fallstudie 1: Kostenvergleichsrechnung zu Architektur 2: Lokaler Speicher |
| 14 | Fallstudie 2: Kostenvergleichsrechnung zu Variante 1: externer SAS-Speicher |
| 15 | Fallstudie 2: Kostenvergleichsrechnung zu Variante 2: Hybrid Storage Technologie (S-ATA/SSD) |
| 16 | Fallstudie 3: Kostenvergleichsrechnung zu Variante 1: externer SAS-Speicher |
| 17 | Fallstudie 3: Kostenvergleichsrechnung zu Vairante 2: Hybrid Storage Technologie (S-ATA/SSD) |
3 Abkürzungsverzeichnis
| Abkürzung | Bedeutung |
|---|---|
| ACL | Access Control List |
| ANSI | American National Standards Institute |
| ATA/ATAPI | Advanced Technology Attachment (with Package Interface) |
| CIFS | Common Internet File System |
| DMA | Direct Memory Access |
| ECMA | Electronical Component Manufacturer Association |
| EEPROM | Electrically Erasable Programmable Read Only Memory |
| FAT | File Access Table |
| FS | File System |
| HDTV | High-Definition TV |
| IDE | Integrated Device Electronics |
| IEEE | Institute of Electrical and Electronics Engineers |
| INCITS | InterNational Committee for Information Technology Standards |
| IO | Input/Output |
| IOPS | Input/Ouput-Operations Per Second |
| iSCSI | internet Small Computer System Interface |
| LVM | Logical Volume Management |
| MFT | Master File Table |
| MLC | Multi Level Cell |
| MPEG | Moving Pictures Expert Group - Standart |
| NFS | Network File System |
| OSTA | Optical Storage Technology Association |
| PDA | Personal Digital Assistant |
| POSIX | Portable Operating System Interface |
| POW | Pseudo OverWrite |
| RAID | Redundant Array of Independent Disks |
| RAM | Random Access Memory |
| RAW | Rohdatenformat |
| SLC | Single Level Cell |
| SOX | Sarbanes-Oxley Act |
| VAT | Virtual Access Table |
| XIP | Execute In Place |
4 Einleitung
Grundlegender Bestandteil dieser Arbeit ist das Zusammenspiel von Dateisystemen und verschiedenen Datenträgern auf denen diese Dateisysteme eingesetzt werden. Im Detail soll die Spezialisierung verschiedener Dateisysteme auf die darunter befindliche Hardware analysiert, bewertet und verglichen werden. Dieses Thema hat eine hohe, stetig wachsende Bedeutung, da gerade bei geschäftskritischen Anwendungen die Wahl des Dateisystems erhebliche Auswirkungen auf die Performance und Zuverlässigkeit des Gesamtsystems hat. Weiterhin erfordern verschiedene Speicherverfahren auch darauf angepasste Dateisysteme, um den jeweiligen Anforderungen gerecht zu werden und um die Vorteile des jeweiligen Mediums auszunutzen beziehungsweise um Nachteile durch intelligente Mechanismen zu kompensieren.
Ziel dieser Ausarbeitung ist die Gegenüberstellung von verschiedenen Dateisystemen und die Untersuchung der Eignung dieser Dateisysteme für spezielle Speichertechnologien. Weiterhin sollen die verschiedenen unterschiedlichen Speichermedien und ihre besonderen Eigenschaften und Anforderungen fixiert werden und die Notwendigkeit von optimierten Dateisystemen begründet werden. Es soll gezeigt werden, welche Dateisysteme unter welchen Bedingungen für welche Speichertechnologie geeignet sind und mit welchen technischen Mitteln das erreicht wird. Neben der technischen Perspektive soll die vorliegende Arbeit auch den wirtschaftlichen Nutzen für die Wahl der verschiedenen Dateisysteme visualisieren. Dafür sollen messbare Kriterien aufgestellt werden, mit deren Hilfe eine objektive Entscheidung zwischen verschiedenen Dateisystemen gezielt getroffen werden kann.
Entsprechend der Zielsetzung werden zunächst die verschiedenen, aktuell verwendeten Speichertechnologien vorgestellt. Neben den magnetischen und optischen Datenträgern, die sich bereits lange etabliert haben, werden auch die momentan noch in starkem Wachstum begriffenen elektrischen Medien (wie zum Beispiel die Solid State Disk) erläutert. Dieser Abschnitt wird abgeschlossen durch eine Einschätzung, welche technische Entwicklung sich hier in der nahen Zukunft vermutlich abzeichnen wird. Ausgehend von diesen verschiedenen Speichertechniken werden aktuelle, spezialisierte Dateisysteme beschrieben. Dazu werden zuerst die grundlegenden Anforderungen an Dateisysteme ermittelt. Neben den hardwarebedingten Anforderungen hinsichtlich des Speichermediums spielen hier vor allem Anforderungen an die Performance und die Sicherheit eine große Rolle. Anschließend werden die verschiedenen Dateisysteme, ihre Besonderheiten und ihre Eignung für verschiedene Speichertechnologien erklärt. Im Anschluss werden die zuvor aufgelisteten Dateisysteme einem ausführlichen Vergleich unter technischen und wirtschaftlichen Gesichtspunkten unterzogen. Neben der Festlegung der Ziele und der Bewertungskriterien für den Vergleich liegt ein Schwerpunkt auf der Darstellung der gewonnenen Ergebnisse und der daraus resultierenden möglichen Interpretation. Abschließend wird diese Arbeit durch ein Fazit und einen Ausblick in die Zukunft abgerundet.
5 Datenträger
5.1 Magnetisch
5.1.1 Definition und Abgrenzung
Magnetische Datenträger nutzen zum Schreiben, Aufbewahren und Lesen von Informationen eine dünne, magnetisierbare Beschichtung. Mit Hilfe eines elektrischen Feldes werden einzelne Teilchen der Beschichtung in eine bestimmte Richtung gedreht und damit ein bestimmter Zustand definiert, welcher dauerhaft wieder ausgelesen werden kann [1].
In die Kategorie magnetischer Datenträger fallen demnach Magnetstreifenkarten, Disketten, Magnetbänder und Festplatten. Da Magnetstreifenkarten lediglich Platz für 1.394 Bit bieten, ist eine Organisation der Daten mittels Dateisystemen nicht zweckmäßig.
Die Verbreitung der Diskette hat mit dem Aufkommen der Flash Speicher rapide abgenommen. Sie sind inzwischen auf dem Speichermarkt bedeutungslos geworden [2]. Von einer detaillierteren Betrachtung wird deshalb abgesehen.
Da Magnetbänder sequenziell beschrieben werden, werden hauptsächlich flache Dateisysteme eingesetzt. Die Nutzung tiefenstrukturierter Dateisysteme für Magnetbänder ist ohne zusätzliche Unterstützung anderer Datenträger nicht denkbar [3].
Auch Festplatten werden sequenziell beschrieben. Durch die hohe Drehgeschwindigkeit der Magnetplatten und der Beweglichkeit der Zugriffskamms zur Positionierung des Schreib- und Lesekopfes, können beliebige Positionen auf der Festplatte allerdings mit einer Verzögerung von ca. 4ms adressiert werden [4] [5]. Sie werden an ihrer Umdrehungsgeschwindigkeiten, ihren internen Cache-Größen, der Fehleranfälligkeit und vor allem ihrer Anbindung an den Host-Controller unterschieden [6].
5.1.2 P-ATA - Parallel Advanced Technology Attachment
Abbildung 1: Schematischer Aufbau einer P-ATA Schnittstelle[7]
|
Das von der IDE-Schnittstelle (Integrated Device Electronics) verwendete parallele ATA definiert ein Software-Protokoll, welches die Kommunikation zwischen Massenspeichern und dem Computer ermöglicht und wurde 1994 durch die American National Standards Institute (ANSI) als Norm verabschiedet. Es ermöglicht die reibungslose Kommunikation zwischen maximal zwei Massenspeichern und einem Controller, wobei ein direkter Datenaustausch zwischen den Massenspeichern nicht möglich ist [8]. Hierzu wird intern eine Daisy Chain aufgebaut (Verbindung mehrerer Geräte über denselben Bus und dasselbe Protokoll[9]), wobei die Geräte als Primary, respektive Slave, bezeichnet werden. Die parallele Anbindung von Festplatten wird heute nur noch in Laptops, älteren privaten Rechnern und älteren Desktops am Arbeitsplatz eingesetzt. Ihre Verbreitung sinkt mit dem vermehrten Einsatz von seriellem ATA.
5.1.3 S-ATA - Serial Advanced Technology Attachment
Unter der Bezeichnung S-ATA ist eine Schnittstelle definiert, welches auf dem ATA-Standard basiert. Sie wird in ANSI INCITS 397-2005, als Teil des ATA/ATAPI-7 vorgestellt. Das Protokoll wurde hierzu komplett umgeschrieben und in 3 Einzelteile zerlegt: das Protokoll (v1), die parallele (v2) und die serielle Implementierung (v3).
Abbildung 2: Schematischer Aufbau einer S-ATA Schnittstelle[10]
|
S-ATA definiert hierbei einen, für Hochgeschwindigkeit ausgelegten, vollständigen Ersatz des parallelen ATA zur Anbindung von Massendatenträgern an ein Hostsystem. Im Gegensatz zu P-ATA, arbeitet es bitseriell und auf Basis der Gigabit-Technologie. Ein weiterer Unterschied zu P-ATA ist, dass S-ATA maximal vier Geräte pro Adapter verwalten kann [11].
Klarer Vorteil gegenüber P-ATA ist die Signallaufzeit und die damit schnellere Datenübermittlung. So erreichen aktuelle Konfigurationen bereits Übertragungsraten bis 3.0Gb/s [12] [13].
5.1.4 SCSI - Small Computer System Interface
Wie P-ATA arbeitet SCSI auf Basis einer parallelen Verbindung in einem Bus-System. Es ist allerdings in der Lage, bis zu 15 Geräte in einer Daisy Chain zusammen zu schließen und zu verwalten. Hauptvorteil gegenüber P-ATA ist, dass alle Geräte gleichzeitig angesprochen werden können und auch gleichzeitig antworten können. Dadurch wird ein wesentlich höherer Datendurchsatz ermöglicht, was die Systemleistung in modernen Multiprozess-Systemen enorm erhöht [14]. Die meisten produktiven professionellen Serversysteme sind heute mit SCSI-Festplatten ausgestattet. Doch wie P-ATA kommt SCSI aufgrund der Signallaufzeit an die Grenzen der maximalen Datenübertragungsrate. In naher Zukunft wird auch diese Schnittstelle zugunsten des Nachfolgers (SAS) abgelöst werden.
5.1.5 SAS - Serial Attached SCSI
Als bitserielles Interface nutzt SAS, wie S-ATA, eine Punkt-zu-Punkt Verbindung zwischen zwei Endgeräten (siehe Abbildung 2). Intern konfiguriert sich die Verbindung als Gigabit-Netzwerk. Im Gegensatz zu S-ATA, kann dieses Netzwerk ausgebaut werden. Wie Switche im Netzwerkumfeld, können an SAS-Hostadapter Edge-Expandern angeschlossen werden, welche bis zu 128 Endgeräte verwalten können. Reicht diese Kapazität nicht aus, können zwischen Hostadapter und Edge-Expander bis zu 128 Fanout-Expander installiert werden. Diese sind selbst in der Lage, bis zu 128 Edge-Expander zu verwalten, womit einem einzelnen SAS-Hostadapter 16.384 Festplatten zur Verfügung gestellt werden können [15]. Dass beide Standards dennoch sehr ähnlich sind, zeigt die Tatsache, dass beide auf der gleichen Gigabit Technologie beruhen, die S-ATA-Geräte sogar an SAS-Hostadaptern angeschlossen werden können (meist aber nicht umgekehrt) [16].
SAS ermöglicht aktuell Datenübertragungsraten bis zu 600MB/s, was einer 6Gb/s–Verbindung, und somit doppelter Leistung von S-ATA entspricht. [17] Zusätzlich ist im Standard ein Verbund von 2 Leitungen zur Verdopplung der Datenrate vorgesehen. Dieser soll allerdings erst beim Anschluss schneller Solid State Disks zur Anwendung kommen [18].
Im Standard sind allerdings auch bereits Datenraten bis 12Gb/s (mit 12 GX-Interface) vorgesehen [19]. Entsprechende Geräte sind bisher allerdings noch nicht verfügbar.
5.2 Optisch
Optische Datenträger zeichnen sich dadurch aus, dass ein Medium einen Licht- beziehungsweise Laserstrahl unterschiedlich stark reflektiert. Dies wird durch Erhöhungen oder Vertiefungen ("pits" und "lands") realisiert, die spiralförmig auf dem Medium angeordnet sind.
Der Hauptanwendungsbereich von optischen Datenträger ist - ähnlich wie bei magnetischen Datenträger - die Nutzung als Sekundärspeicher. Dies wird durch die Austauschbarkeit und den relativ geringen Preis begünstigt[20]. Optische Medien sind aber nicht nur auf den Computersektor beschränkt. Ein weiterer Anwendungsbereich liegt hier in der Unterhaltungsindustrie, die diese Datenträger als Medium für Audio- und Videodaten nutzt. Ein großer Vorteil gegenüber magnetischen Datenträgern findet sich in der Unterscheidung von nur lesbaren Datenträger (read-only), einmal beschreibbaren Datenträgern (write-once) und wiederbeschreibaren Medien (rewritable)[21]. So haben sich read-only Datenträger auch in der Verteilung von Software und Multimediainhalten etabliert, da diese Medien schnell und kostengünstig vervielfältigt werden können. Wiederbeschreibbare Datenträger spielen beispielsweise eine große Rolle, wenn kostengünstige Backups durchgeführt werden sollen[22].
Als Standards haben sich gerade auch im privaten Bereich die CD und DVD durchgesetzt. Aktuell gewinnt die Blu Ray als relativ junge Technologie für große Speichermengen immer mehr an Bedeutung. Weiterhin entstehen die ersten Standards im holografische Bereich.
5.2.1 CD/DVD
Die CD (Compact Disc) wurde ursprünglich als Ersatz für die Schallplatte entwickelt, hat sich allerdings auch im PC-Bereich schnell durchgesetzt. Die heutige CD-Technologie wurde von Philips entwickelt und im Jahre 1979 vorgestellt. Grundlegende Entscheidungen wurden damals von Philips getroffen, beispielsweise dass die Datenspur von innen nach außen verläuft und dass der Durchmesser exakt 12 Zentimeter betragen soll. 1980 wurde der Compact Disc Standard formal veröffentlicht. In Zusammenarbeit mit Sony wurde die Compact Disc Ende 1982 in Europa und Japan und 1983 in den Vereinigten Staaten von Amerika eingeführt[23]. Anstelle der Nadel bei einer Schallplatte wird zur Abtastung der Pits und Lands ein roter Laser verwendet. Allerdings kann Licht aufgrund der Beugung der Linse in Zusammenhang mit der Wellennatur des Lichts nicht auf einen beliebig kleinen Durchmesser gebündelt werden. Um einen möglichst optimal gebündelten Laserstrahl zu erreichen spielt die numerische Apertur der Linse eine und die Wellenlänge des Lichts eine große Rolle. Die numerische Apertur ist das Produkt aus dem Winkel und dem Brechungsindex der Umgebung. Der Durchmesser des Lasers ist je kleiner desto kleiner die Wellenlänge des Lichts und desto größer die numerische Apertur ist. Allerdings wird das optische System instabiler wenn die numerische Apertur größer wird. Wird hingegen ein Laser mit kleinerer Wellenlänge verwendet, kann die numerische Apertur bei gleichbleibendem Durchmesser des Laserstrahls verringert werden. Dieses Zusammenspiel wurde über die verschiedenen Generationen der optischen Medien stets verbessert[24].
Auch die DVD arbeitet mit einem roten Laser, allerdings mit einer anderen Wellenlänge, was sich in den unterschiedlichen Kapazitäten niederschlägt[25]:
| CD | DVD | |
|---|---|---|
| Kapazität | 0,65 GiB | 4,7 GiB (Single Layer) |
| Wellenlänge des Lasers | 780nm | 650nm |
| Datenrate | 1,47 Mb/s | 11,08 Mb/s |
Mit der DVD begann man auch erstmal mehrere Layers auf einem Datenträger unterzubringen. Der erste Layer besteht dabei aus dem gleichen Material (reflektiert nur einen Teil des Lichts) wie eine DVD mit nur einem Layer. Der zweite Layer hingegen besteht aus einer voll reflektierenden Aluminiumschicht. Somit kann von der DVD gelesen werden, ohne das die DVD gedreht werden muss. Die unterschiedlichen Ebenen werden durch verschiedene Brennpunkte angesprochen[26].
Abbildung 3: DVD - Dual Layer[27]
|
5.2.2 Blu-Ray Disc
Als blaue Laser für die Industrie in größerer Zahl verfügbar wurden, entwickelte sich eine optische Speichertechnologie, die eine noch höhere Datendichte erreichen konnte. Die Blu Ray Disc entstand aus der Anforderung heraus, dass Filme, die bislang auf einer DVD abgespeichert werden konnten, nun in einer deutlich höheren Auflösung verfügbar wurden. Während eine DVD einen Film von 2 Stunden und 15 Minuten in MPEG-2-Kompression speichern konnte, ist eine Blu Ray Disc in der Lage Speicherplatz für die Aufnahme eines HDTV-Signals für über 2 Stunden bereitzustellen.
Damit sich die erhöhte Speicherkapazität nicht auf eine Vergrößerung des Datenträgers auswirkt, wurde dies durch verschiedene Techniken umgesetzt[28].
5.2.2.1 Blau-violetter Laser
Der namensgebende blaue Laser hat eine kürzere Wellenlänge (400 nm) als die DVD (650 nm) und kann somit die Daten enger und kleiner auf dem Datenträger ablegen. Dieses Verfahren erhöht die Kapazität der Blu Ray Disc bereits auf ca. 12 Gigabyte.
5.2.2.2 Verringerung der Dicke der Substratschicht
Die Substratschicht wurde gegenüber der DVD von 0,6 mm auf 0,1 mm verkleinert. Durch die Verringerung der Dicke der Substratschicht, muss der Laser nun nur noch eine sehr viel kürzere Distanz bis zur Datenträgerschicht zurücklegen. Folglich verringert sich die Streuung des Lichts und der Laser kann exakter arbeiten. Dies hat allerdings den Nachteil, dass die Datenschicht nun weitaus weniger durch die Substratschicht geschützt ist.
5.2.2.3 Erhöhung der numerischen Apertur
Durch die nun weitaus dünnere Substratschicht, kann eine höhere numerische Apertur (0,85) gewählt werden. Dies ermöglicht eine erhöhte Bündelung des Lasers und führt dazu, dass der Laser noch feiner justiert werden kann. Folglich kann ein weitaus kleinerer Laserpunkt von nur 0,58 µm gegenüber 1,32 µm (DVD) realisiert werdem.
Ähnlich wie bei der DVD, können auch bei der Blu Ray Disc mehrere Layer verwendet werden, was die Speicherkapazität zusätzlich vervielfacht. Eine Dual Layer Blu Ray Disc kann somit beispielsweise eine Kapazität von 50 GB erreichen[29].
5.2.3 Holographic Disc Storage (HDS) - HVD / InPhase tapestry
| Holographic Disc Storage, kurz HDS, gehört zu den optischen Speichertechnologien und unterscheidet sich zu Speichertechniken wie der CD, DVD oder Blue-Ray Disc grundlegend. Im Unterschied zu diesen werden die Daten nicht spiralförmig über "pits" und "lands" und ggf. mehreren Schichten gespeichert (siehe Kapitel 5.2), sondern unter Verwendung von dreidimensionalen Hologrammen. Daraus resultierend werden Daten auf ein HDS-Medium nicht Bit für Bit sequenziell nacheinander geschrieben, sondern gebündelt sequenziell. Im Fall der HDS Technologie "tapestry" der Firma InPhase Technologie werden immer mindestens 1Mbit an Daten pro Hologramm abgelegt[30].
Das Konzept des HDS für den Massenmarkt wird durch zwei konkurrierende Standards/Systeme vorangetrieben, die auf ähnliche Verfahren zurückgreifen. |
Abbildung 4: HVD Laufwerk und Medium: tapestry 300r[31]
|
"tapestry" ist das HDS System der Firma InPhase Technologie (siehe Abbildung 5) welches sich in der ersten Generation kurz vor der Markteinführung befindet. Dem gegenüber steht die "Holographic Versatile Disc", kurz HVD, die von einem Konsortium entwickelt und standardisiert wird. Diesem Konsortium gehören unter anderem Hersteller wie Fujifilm, ALPS, Hitachi und Pulstec an[32]. Bisher ist noch kein auf der HVD basierendes Produkt auf dem Markt vertreten, obwohl die ersten Standards für HVD-Medien seit Mai 2007 verabschiedet sind[33] [34] [35].
Abbildung 5: Zwei-Achsen und Collinear Technik von Optware[36]
|
Schon vor dem Aufkommen der Standards HVD und tapestry wurden HDS Systeme entwickelt, die auf Grund der für die Lese- und Schreibfunktion benötigten Präzision und damit verbunden Komplexität, nicht für den Massenmarkt brauchbar waren. Eins dieser Probleme war beispielsweise der Entwurf einer möglichst kompakten und robusten Technik mit der Hologramme in ein Medium geschrieben und daraus gelesen werden können. Die HVD Alliance benutzt dabei die von Optware entwickelte Technik "Collinear", anstelle der klassischen zwei Achsen-Technik (siehe Abbildung 6)[37] [38]. InPhase hat für tapestry ebenfalls eine alternative Technologie entwickelt, die allerdings nicht für den Consumermarkt geeignet ist [39].
Abbildung 6: HVD Disc Struktur[40]
|
HDS Medien werden ähnlich wie die CD, DVD oder BD aus Polymer hergestellt und sind mehrschichtig aufgebaut (siehe Abbildung 3). Die oberste Schicht bildet dabei eine Schutzschicht. Darauf folgt die Schicht in der die Hologramme gespeichert werden gefolgt von einem Abstandshalter und der Reflexionsschicht für den Lichtstrahl des blauen oder grünen Lasers. Anschließend folgt wieder eine Abstandsschicht und danach eine Reflexionsschicht aus Aluminium für den roten Lichtstrahl. Zwischen der Abstandsschicht und der aus Aluminium bestehenden Schicht befinden sich "pits", die unter Hilfenahme des roten Lasers abgetastet werden und zur genauen Steuerung des Lese- oder Schreibvorgangs benutzt werden. Durch die Verwendung der Steuerung über "pits" soll bei der HVD Technologie auf teure Hochpräzisionsservos verzichtet werden können[41].
tapestry Medien bestehen aus zwei speziellen Kunststoffen mit guten Eigenschaften in Bezug auf das Verfahren und das geplante Einsatzgebiet von tapestry. Die drückt sich aus in der Lichtempfindlichkeit, Herstellungsgüte, physikalischen Stabilität des Mediums und einer Lebensdauer von 50 Jahren[42].
| HVD | tapestry | |
| Hersteller | Diverse, Konsortium: HVD Alliance | InPhase Technologies |
| Geräte vorgestellt | nein | ja - 1. Generation: tapestry 300r[43] |
| Laserdiode | grün oder blau + rot | blau (405nm)[44] |
| Kapazität | Medienstandards für 100 GiB[45], 200 GiB[46]; 500 GiB geplant[47] | 1. Generation: 300 GiB[48] |
| Medientyp | HVD-R, HVD-ROM[51] | WORM[52] |
| RW-Medien | In Entwicklung | In Entwicklung[53] |
| Primäre Zielgruppe | Privatkunden (Nachfolger der BD)
Geschäftskunden | Geschäftskunden[54] |
5.3 Elektrische Datenträger
Im Gegensatz zu den bisher beschrieben Speicherformen, werden die Daten bei elektronischen Datenträgern mit der Hilfe von elektronischen Bauelementen, hauptsächlich in Form von integrierten Schaltkreisen, festgehalten. Hierbei werden verschiedene Formen der elektronischen Speicherung unterschieden:
- Flüchtig
Bei flüchtigen Speichermedien gehen die Daten verloren, sobald sie nicht ständig aufgefrischt werden oder wenn die Stromversorgung unterbrochen wird.
- Permanent
Permanenter Speicher zeichnet sich dadurch aus, dass eine einmalig gespeicherte Information dauerhaft gespeichert bleibt und sich nicht mehr ändern lässt.
- Semi-permanent
Ähnlich wie permanenten Speicher kann auch semi-permanenter Speicher Informationen dauerhaft festhalten. Allerdings bleiben die persistierten Daten weiterhin änderbar.
5.3.1 RAM - Disk
Die RAM-Disk gehört prinzipiell zu den flüchtigen Speichermedien. Grundsätzlich wird ein definierter Bereich des Arbeitsspeichers als Festplatte in das Betriebssystem eingebunden. Somit wirkt die RAM-Disk wie jede andere Festplatte die als Peripheriegerät angebunden ist. Ähnlich wie eine Festplatte ist die RAM-Disk über den IO-Bus mit dem Prozessor verbunden und wird auch über einen entsprechenden Gerätetreiber angesprochen[55].
Das heißt, der Gerätetreiber sendet Anfragen in Form der Blöcke auf der "Festplatte" die ausgelesen oder beschrieben werden soll. Diese Anfragen werden von der RAM-Disk entsprechend umgesetzt. Da aber die RAM-Disk die Daten nicht auf einer sich rotierenden magnetischen Scheibe ablegen muss, sondern auf einen wahlfreien Speicher zugreifen kann, ergeben sich maßgebliche Performancevorteile. Während die Latenz (beziehungsweise Zugriffszeit) bei magnetischen Datenträgern je nach Typ und Hersteller bei wenigen Millisekunden liegt, ist die Latenz bei einem Zugriff auf den Arbeitsspeicher auf wenige Nanosekunden begrenzt.
5.3.2 Flash Speicher
Flash-Speicher gehören zu den semi-permanenten Speichermedien, da die Daten auch nach Abschaltung der Stromversorgung persistent gespeichert sind. Diese Technologie bietet eine vergleichsweise (z.B. gegenüber Festplatten) geringe Latenz und somit eine hohe Datendurchsatzrate beim Lesezugriff. Weitere Vorteile gegenüber magnetischen Festplatten sind der geringere Platzbedarf, die geringere Stromaufnahme, das geringere Gewicht und die größere Schocktoleranz. Diese Argumente sprechen für einen Einsatz in mobilen Endgeräten, wie zum Beispiel Notebooks, Handhelds und PDAs. Vorteile gegenüber RAM-Bausteinen sind die erhöhte Dichte der Speicherzellen und der geringere Preis pro Speichereinheit[56] [57].
5.3.2.1 Technologie
Flash-Speicher ist eine besondere Form des EEPROM (Electrically Erasable/Programmable Read Only Memory). Diese Speicherform wurde nach ihrem vergleichsweise schnellen Löschverfahren benannt, da das bitweise Löschen der ursprünglichen EEPROMs viel Zeit in Anspruch nahm[58].
Im Prinzip beruht diese Speicherform darauf, dass elektrische Ladungen auf sogenannten Floating Gates eines Feldeffekttransistors gespeichert werden. Das Floating Gate stellt hierbei die eigentliche Speicherfunktionalität bereit. Die Grundfunktionalitäten wie Lesen, Schreiben, Löschen funktionieren anders als bei bisherigen Speicherformen, wie zum Beispiel RAM oder Festplatten. Das Setzen eines Bits von 0 auf 1 kann nicht bitweise passieren. Vielmehr muss bei Flashspeichern einer ganzer Block zurückgesetzt beziehungsweise gelöscht werden. So ein Bereich wird als Physical Erase Unit bezeichnet[59].
Flashspeicher ist in seiner Lebensdauer begrenzt. Diese Lebensdauer wird meist in der möglichen Anzahl von Löschzyklen beschrieben. Typischerweise kann auf jeder Physical Erase Unit ungefähr 100.000 Löschvorgänge durchgeführt werden. Darüber hinaus lässt die Zuverlässigkeit der Blöcke stark nach, das heißt die Informationen können nicht mehr sicher dauerhaft gespeichert werden. Da sich diese Beschränkung auf die verschiedenen Blöcke bezieht, wird versucht die Löschzyklen auf dem gesamten Medium zu verteilen, um die effektive Nutzungsdauer des Flash-Medium zu erhöhen. Diese Technik wird als Wear Leveling bezeichnet[60].
Im Bereich der Flashspeicher haben sich zwei Architekturen durchgesetzt:
5.3.2.1.1 NOR - Flash
Die NOR-Flash Variante bietet einen wahlfreien Zugriff und kann direkt vom Prozessor angesprochen werden. Dieser Typ ist in Blöcke mit einer Größe von beispielseweise 128 KiB unterteilt. Dadurch, dass diese Speicherform ähnlich wie ein RAM-Baustein einen wahlfreien Zugriff hat, können auch Mikroprozessoren NOR-Flash für XIP (eXecute In Place) nutzen. Das bedeutet, dass Programme, die sich auf dem Flashspeicher befinden, direkt ausgeführt werden können, ohne zuvor in den Arbeitsspeicher kopiert zu werden. Die Schwachstelle von NOR-Flash liegt in dem hohen Zeitbedarf bei Lösch- und Schreibvorgängen. Dafür bietet dieser Flashspeicher aber eine höheren Datendurchsatz bei Lesevorgängen.
5.3.2.1.2 NAND - Flash
NAND-Flash ist die günstigere Variante und ist in Blöcke mit einer Größe von typischerweise 8 KiB unterteilt. Gegenüber NOR-Flash bietet dieser Typ keinen wahlfreien direkten Zugriff, dagegen aber weitaus mehr Performance bei der Bearbeitung von Löschzyklen. Weiterhin sind bei NAND-Flash die Blöcke wiederum in Pages unterteilt, die typischerweise eine Größe von 512 Bytes haben. Davon sind bereits 16 Bytes für Fehlererkennungsmechanismen reserviert. Da der NAND-Flash nicht direkt adressierbar ist, muss ein Controller angesteuert werden. Der Controller wird nicht auf Byte-Ebene sondern auf Page-Ebene angesprochen. NAND-Flash wird geschrieben, indem zunächst die Bytes in einem Buffer vorgehalten werden, bevor der Schreibvorgang angestoßen wird. Eine Page kann bei NAND-Flash kann während eines Löschzyklus nur wenige Male beschrieben werden. Nach diesen wenigen Modifikationen wird das Zurücksetzen von Bits auf der Page unzuverlässig. Die gesamte Erase Unit muss gelöscht werden, bevor weitere Änderungen auf der Page sicher durchgeführt werden können Dieses mehrfache Beschreiben einer Page ist aber auch wieder dahin gehend beschränkt, dass die einzelnen Bits bei Schreiboperationen nur einmalig von 1 auf 0 gesetzt werden können. Wenn eine Page beispielsweise nur aus einem Byte besteht, dann kann die Page nur in eine "Richtung" mehrfach geändert werden[61]:
| Zustand | Darstellung |
| Zustand nach Block-Erase | 11111111 |
| Erstes Update | 11010111 |
| Zweites Update | 10010111 |
| Drittes Update | 10010001 |
| ... | |
| Letztes Update | 00000000 |
Auch die Flashzellen selbst können in zwei verschiedene Kategorien eingeteilt werden. SLC-Flash (Single-Level-Cell) beschreibt Flashzellen die jeweils nur einen Binärwert darstellen. MLC-Flash hingegen ist in der Lage pro Flashzelle mehere Binärwerte abzuspeichern. Während SLC zwei Ladezustände (1 und 0) speichern kann, ist MLC-Flash beispielsweise dazu in der Lage 4 Ladezustände abzuspeichern und somit 2 Bits zu kodieren (00, 01, 10, 11). MLC-Flash ist etwas anfälliger, da aufgrund der geringeren Spannungstoleranz (4 Ladezustände anstatt 2) leicht der falsche Zustand erkannt wird. Deshalb sind bei MLC-Flash aufwendige Fehlerkorrekturverfahren nötig. Weiterhin sind Schreib- und Leseoperationen auch entsprechend langsamer. Allerdings kann mit der gleichen Menge an Speicherzellen doppelt so viel Speicherplatz (gegenüber SLC-Flash) zur Verfügung gestellt werden. SLC-Flash bietet eine vergleichsweise höhere Geschwindigkeit und auch eine bessere Verfügbarkeit, weshalb sich dieser Typ auch gerade für den Enterprise-Bereich anbietet[62].
5.3.2.2 Solid State Drive
Das Solid State Drive etabliert sich momentan als Alternative zu herkömmlichen magnetischen Festplatten. Dabei können diese „Drives“ ähnlich wie ihre magnetischen Konkurrenten angesprochen werden ohne aber rotierende Magnetplatten oder bewegliche Teile wie Leseköpfe zu verwenden. Solid State Drives können generell zwei verschiedene Prinzipien zu Grund liegen: Flash und RAM-Bausteine. Im Folgenden werden nur die flashbasierten Solid State Drives beschrieben, da die RAM-Disk bereits im entsprechenden Abschnitt beschrieben ist. Solid State Drives haben gerade im Bereich des Mobile Computing große Vorteile gegenüber herkömmlichen Magnetfestplatten. Die Solid State Disk verbraucht weniger Strom und ist resistenter gegenüber äußeren Einwirkungen wie Stößen und Schlägen. Heutige Flash-SSDs werden über die gängige S-ATA-Schnittstelle angesprochen und können von dem Endgerät wie eine normale Festplatte verwendet werden. Die Solid State Disk besteht aus einem Mikrocontroller und einer Reihe von NAND-Flash-Chips. Aus Kostengründen werden meist MLC-Flashzellen verbaut. Hybrid-SSDs nutzen die Vorteile beider Varianten indem aus den eben genannten Kostengründen ein verhältnismäßig kleiner Anteil von SLC-Zellen verbaut wird. Der Großteil besteht wiederum aus MLC-Zellen, die als Massenspeicher dienen[63].
Abbildung 7: Schematischer Aufbau einer Hybrid Solid State Disk[64]
|
Eine übliches Layout für so eine Hybrid Solid State Drive ist in Abbildung 8 dargestellt. Ein Array von Flashzellen wird von einem Mikrocontroller verwaltet, teilweise gibt es auch einen kleinen RAM-Baustein der vom Controller verwendet wird. Das in die Firmware integrierte Flash Translation Layer sorgt dafür, dass die Solid State Disk wie eine Festplatte angesprochen kann. Diese Zwischenschicht enthält eine Zuordnung von Blöcken zu physikalischen Sektoren. Jeder Block wird dabei einer Physical Erase Unit und einem Sektor-Index innerhalb dieser Unit zugeordnet. Diese Mapping-Informationen werden teilweise sowohl im Arbeitsspeicher als auch im Flashspeicher selber gehalten. Gerade bei Dateisystemen, die nicht für Flashspeicher optimiert sind, macht es Sinn diese Informationen zum Teil im Arbeitsspeicher zu verwalten, um die Lebensdauer des Flashspeichers nicht unnötig zu verringern[65].
Bei normalen Solid State Drives werden nur ein Typ von Flashzellen verbaut. Wie in der Abbildung ersichtlich, verwendet eine Hybrid-SSD sowohl SLC- wie auch MLC-Flash. In diesem Zusammenhang wird von "heißen" und "kalten" Daten gesprochen. Entsprechend sorgt der Controller dafür, dass zunächst geprüft wird, ob ein ankommendes Datenpaket "heiß" oder "kalt" ist. "Heiße" Daten, also Daten die oft benötigt werden, liegen vorzugsweise auf den SLC-Zellen. "Kalte" Daten wandern direkt zum MLC-Flash. Dies resultiert aus den schon genannten Eigenschaften beider Flashvarianten. SLC-Flash hat eine höhere Lebensdauer und bessere Zugriffszeiten beim Lesen wie auch beim Schreiben, ist aber vergleichsweise teuer. Somit ist diese Kategorie bestens dafür geeignet hochfrequentierte Daten zu verarbeiten. Somit kann die Gesamtperformance der Solid State Disk erhöht werden[66].
Im Folgenden soll die Solid State Disk auf Basis von Flashbausteinen abschließend mit der Magnetfestplatte verglichen werden, da sich die Solid State Disk sich in vielen Bereich als direkte Konkurrenz zur normalen Festplatte entwickelt hat. Typische Zugriffszeiten für einen Flashspeicher liegen in einem Zeitfenster von ungefähr 35-100 Mikrosekunden. Dies unterscheidet sich je nach Bauart und Hersteller. Eine herkömmliche Festplatte hat aufgrund ihrer mechanischen Beschränkungen eine Zugriffszeit von circa 5000-10000 Mikrosekunden. Daraus ergibt sich ein Faktor von 100 bei der maximalen Zugriffszeit. Während Festplatten heutzutage in vielen Konfigurationen bislang einen Flaschenhals darstellten, kann die Gesamtperformance solcher Systeme durch den Einsatz von Flash-SSDs erheblich gesteigert werden. Hinsichtlich Datenkapazität hat die HDD sicherlich immer noch die Nase vorn. Zwar konnte bereits eine Flash-SDD mit einem Terabyte Volume hergestellt werden, aber im Consumer-Bereich sind 64-128 Gigabyte eher der aktuelle Standard. Auch der Preis pro Gigabyte ist bei einer SSD immer noch weitaus höher. Allerdings ist dies auch dadurch bedingt, dass die HDD bereits sehr viel länger am Markt ist, als die SSD. Auch hier ist ein Preisangleich in der Zukunft zu erwarten. Anders sieht das in anderen Bereichen aus, wie z.B. dem Stromverbrauch und der Wärmeentwicklung. Bedingt durch die rotierenden Magnetscheiben ist die Wärmeentwicklung und auch der Stromverbrauch einer Hard Disk höher als bei den Solid State Disks. Ebenfalls resultiert aus den mechanischen Eigenschaften der HDD ein erhöhter Geräuschpegel, der in der Form bei SSDs nicht vorhanden ist. Dies sind wichtige Faktoren, die einen Einsatz beispielsweise in mobilen Endgeräten begünstigen. Solid State Disk auf Basis von RAM-Bausteinen teilen viele Vorteile der flashbasierten Solid State Disks gegenüber HDDs, wie zum Beispiel eine erhöhte Zugriffsgeschwindigkeit (sogar noch höher als bei Flash-SSDs), eine geringere Wärmeentwicklung, eine geringere Stromaufnahme und einen minimalen Geräuschpegel. Allerdings sind RAM-Disks der flashbasierten Technik in manchen Punkten unterlegen. Neben den höheren Kosten ist der größte Nachteil wohl die Volatilität der RAM-Disk. Da heißt, wenn der Strom abgeschaltet wird, müssen vorher alle Daten, die auf der RAM-Disk vorhanden sind, auf einem anderen Medium persistent gespeichert werden oder sie gehen entsprechend verloren[67].
5.4 Zukünftige Entwicklung
Festplatten werden aufgrund ihres Einkaufspreises und ihrer Gesamtkapazität auch in naher Zukunft der bevorzugte Sekundärspeicher sein, wenn es um die Verwaltung von großen Datenmengen geht.
Da sich die Umdrehungsgeschwindigkeit der Magnetplatten in den letzten fünf Jahren nicht weiter verbessert hat, scheinen die Entwicklungen der Festplatten vor allem in der Verdichtung des Blockabstandes zwischen zwei Blöcken und damit einer Vergrößerung der Gesamtkapazität zu laufen. So sind inzwischen bereits Festplatten mit einer Gesamtkapazität von 2 Terrabyte erhältlich[68].
Die Forschung ist allerdings auch bereits auf der Suche nach neuen Materialien, welche als magnetische Datenträger dienen können. Mit Hilfe eines Rastermagnetkraftmikroskops sind Forscher der Universität Hamburg in der Lage, den Spin einzelner Atome zu messen und zu bestimmen. Da nur zwei Zustände möglich sind, können damit binäre Informationen dargestellt werden.[69].
Bei den optischen Datenträgern geht die Entwicklung aktuell in mehrere Richtungen. So definierte im Juni 2008 die ECMA den DVD-Standard für zweiseitige, zweischichtige Datenträger mit einer Gesamtkapazität von 17.08 Gigabyte[70]. Mit der Holographic Versatile Disc ist eine zweite Forschungsrichtung beschrieben, welche zukünftig ein Datenträgervolumen bis zu 4 Terrabyte erreichen soll. Der aktuelle Standard ist 2007 von der ECMA veröffentlich worden[71]. Dass auch beim Trägermaterial geforscht wird, zeigt das Beispiel der Tesa-Scribos, bei welcher mit Laser handelsüblicher Tesa-Film beschrieben wird[72].
Mit den Solid State Disks ist erstmals ein Ersatz der herkömmlichen Festplatte für den professionellen Gebrauch entwickelt worden und werden bereits in Server Systemen als Sekundärcache zwischen langsamer Magnetplatte und schnellem Hauptspeicher im Eingesetzt. Erste Versuche, die Magnetplatten in der Wirtschaft gänzlich durch Solid State Disks zu ersetzen, sind vor allem im Midrange und High-End Bereich, vorgenommen worden[73].
6 Optimierte Dateisysteme
Auf den nachfolgenden Seiten werden verschiedene Dateisysteme die sich in den letzten Jahren am Markt bewährt haben beschrieben und ihre Einsetzbarkeit in Verbindung mit den unter Kapitel 5 - Datenträger vorgestellten Speichertechnologien untersucht. Wirtschaftliche Aspekte werden zunächst nicht berüchsichtigt. Diese werden im Kapitel Kapitel 7 - Vergleich anhand von Fallbeispielen näher untersucht.
Einige Speichertechnologien sollten sehr kontrolliert eingesetzt werden, da sie bspw. nur eine geringe Anzahl von Schreibvorgänge pro Block zulassen, hier muss dann u.a. die Anordnung der Daten auf dem Datenträger berücksichigt werden. Optimierte Dateisysteme greifen diese Problematik auf und versuchen gezielt diese Schwächen zu umgehen. Dateisysteme die sich auf den Einsatz in Clusterumgebungen konzentrieren werden nicht betrachtet. Das ein oder andere hier vorgestellte Dateisystem mag sicherlich Eigenschaften haben, die auch solchen Cluster Dateisystemen zuzuordnen sind, auf diese wird hier aber nicht eingegangen.
6.1 Anforderungen
Datenträger stellen Speicher in Form von adressierbaren Blöcken zur Verfügung. Der Datenzugriff erfolgt für den Benutzer völlig transparent, der tatsächliche Speicherort stellt sich für ihn nur in Form von Dateien und Verzeichnissen dar. Für die eigentliche Anordnung auf dem Datenträger ist das Dateisystem zuständig.
Die Anforderungen an ein Dateisystem ergeben sich häufig aus der verwendeten Speichertechnologie. Neben Performanz und Ausfallsicherheit ist es aufgrund einiger Technologien notwendig, die Art und Weise der Implementierung innerhalb des Dateisystems genauer zu betrachten, um so auf bestimmte Eigenschaften von einigen Datenträger einzugehen. Die unter Kapitel über die Optischen Datenträger vorgestellten "Optischen Medien" weisen z.B. nur eine begrenzte beschreibbarkeit auf. Diese Eigenschaft muss von einem Dateisystem beachtet werden. Unter Kapitel 2 - Datenträger wurden einige weitere Eigenschaften verschiedener Speichertechnologien vorgestellt, auf die in den jeweiligen Ausführungen bezug genommen wird. Moderne Dateisysteme stellen über die Basisdienste hinaus in der Regel drei weitere Funktionen bereit: Journaling, Snapshots und dynamische Dateisystemerweiterung [74].
Beim Journaling handelt es sich um einen Mechanismus, der die Konsistenz des Dateisystems gewährleisten soll. Dateisysteme die diese Technik implementiert haben, schreiben jede Änderung zunächst in eine Logdatei, die für den Anwender nicht sichtbar ist. Bei einem Systemausfall braucht das Dateisystem dann nur die fehlenden Daten aus dem Logfile zurückspielen, um so die Konsistenz der Daten wiederherzustellen [75].
Snapshots frieren den Zustand des Dateisystems zu einem definierten Zeitpunkt ein und erstellen innerhalb weniger Sekunden eine Kopie des Datenträgers. Diese Technologie ist auch von Disksubsystemen bekannt und wird oft als Instant Copy bezeichnet. [76]. Ein wesentlicher Vorteil der Snapshot Technologie aus dem Dateisystem heraus ist die von der Hardware unabhängige Nutzbarkeit.
Verschiedene Verwaltungsfunktionen für Datenträger sind häufig in einer Zwischenschicht innerhalb des Betriebssystems realisiert. Die Zwischenschicht wird meist als Volume Manager bezeichnet und stellt die Verbindung zwischen dem Dateisystem und den physikalischen Festplatten her. Die Grundfunktion des Volume Managers besteht darin, mehrere physikalische Festplatten zu einer virtuellen zusammenzufassen und die Partitionsstruktur des Dateisystems zu verwalten. Einige Dateisysteme sind auf spezielle Betriebssysteme optimiert, so dass verschiedene Aufgaben dann direkt vom Betriebssystem durchgeführt werden. Das ist z.B. der Fall bei den Windows Dateisystemen wie FAT und NTFS, bei dem Unix File System (UFS) und dem High Performance File System (HFS) die einen Puffer für IO Operationen bereitstellen [77]
6.1.1 Performance
Performance ist ein Hauptkriterium an dem ein Dateisystem gemessen und bewertet werden kann. Der Performancebegriff bezieht sich dabei auf den Datendurchsatz oder die Anzahl der Aufträge pro Zeiteinheit die ein Dateisystem basierend auf einer Speichertechnologie erbringen/bearbeiten kann. Kurz gefasst: Wie schnell und effizient kann es Daten bereitstellen. Die Messung der Performance eines Dateisystems ist dabei nicht einheitlich durchführbar, da die Messmethoden zum Einsatzbereich des Dateisystems passen müssen. Aus diesem Grund haben sich mehrere Kombinationen aus Messmethoden, später nur noch als Benchmarks bezeichnet, entwickelt, die Performancemessungen eines Dateisystems, mit Fokus auf einen speziellen Einsatzbereichs, durchführen. Trotz der sich daraus ergebenen Möglichkeiten für Variationen haben sich für jeden Einsatzbereich einige wenige Benchmarks etabliert und Messmethoden durchgesetzt, aus denen die Anforderungen an ein Dateisystem hervorgehen und folgend kurz vorgestellt werden.
Der Benchmark Postmark, entwickelt von der Firma NetApp, führt Messungen durch, die für den Einsatz im Bereich des elektronischem Mailverkehr und e-Commerce über das Internet von Bedeutung sind. Die Daten in diesem Einsatzbereich liegen in sehr vielen kleinen Dateien vor, die keine hohe Lebensdauer besitzen. Um diesem gerecht zu werden basiert der Postmark-Benchmark auf dem Erzeugen, Löschen, Lesen und Ändern(Anhängen von Daten) von Dateien unter Messung der Anzahl pro Zeiteinheit dieser Transaktionen. Transaktionen werde immer im Paar ausgeführt um ein möglichst realistisches Szenario zu erzeugen, so dass wenn eine Datei mit zufälliger Länge und Text erstellt wird, ebenfalls eine zufällige Datei gelöscht wird [78].
Bonnie++ ist ein in C++ geschriebener Benchmark, der auf den Tests des Benchmarks Bonnie aufbaut. Die letzte Aktualisierung des Benchmarks stammt aus dem Jahr 2003, trotzdem wird er immer noch häufig verwendet. Insgesamt besteht Bonnie++ aus zwölf Tests. Die ersten sechs sollen Last in Bezug auf das Arbeiten mit großen Dateien erzeugen. Dabei wird eine Datei in verschiedenen Varianten geschrieben und gelesen. Anschließend erfolgt an Test um zufällige Zugriffe auf das Dateisystem zu erzeugen. Die letzten sechs beziehen sich auf Operationen (anlegen, Informationen abrufen und löschen) mit vielen kleinen Dateien. Damit die Hardware ausgelastet werden kann, ist es möglich mehrere Instanzen von Bonnie++ parallel laufen zu lassen [79].
IOzone ist ein weiterer Benchmark um die Leistungsfähigkeit eines Dateisystems und der darunterliegenden Hardware zu testen. Das Ziel dieses Benchmarks ist es den I/O-Durchsatz in Abhängigkeit des zu betrachtenden Einsatzbereichs des Systems zu messen und diese dann für Vergleiche zur Verfügung zu stellen, so dass diese Messwerte beispielsweise bei Konsolidierungen von verschiedenen Diensten (zum Beispiel Datenbankserver und Mailserver) auf eine gemeinsame Serverhardware und -software berücksichtigt werden können. IOzone steht wie die anderen Benchmarks auch für mehrere Plattformen zur Verfügung, wie zum Beispiel für Linux und Windows. Das Test-Portfolie umfasst dabei eine Vielzahl von Lese und Schreiboperationen von Dateien auf Basis des direkten Schreibens und Lesens, über die Bibliotheken fread und fwrite, sowie einer Methode[80]
Wie aus den Tests der Benchmarks abzuleiten ist, beziehen sich die Benchmarks auf die Grundfunktionen eines Dateisystems und versuchen ein Szenario nachzustellen, dass sich an den im Alltag vorkommenden Einsatzgebieten orientiert oder einfach eine möglichst hohe Last erzeugt, ohne dabei Optimierungen zu nutzen die nicht Bestandteil des Dateisystems sind, wie beispielsweise spezielle vom Betriebssystem vorgehaltene Cache-Speicher [81]. Auf Basis dieses Vorgehens und den daraus resultierenden Ergebnissen sind die Anforderungen an die Performance immer in Abhängigkeit mit der Applikation zu formulieren, die später das Dateisystem nutzt/ nutzen soll. Im Fall eines Mailserver ist es daher in der Regel sinnvoll eine hohe Geschwindigkeit in Bezug auf das "parallele" Erstellung, Lesen und speichereffiziente Verwalten von vielen eher kleineren Dateien zu legen, als mit der Übertragungsrate mit der eine große Datei erstellt und gelesen werden kann.
| Mail Server | File Server | Archiv Server | |
| Profil / Eigenschaften | Viele kleine Dateien mit kurzer Lebenszeit | Mittlere Anzahl an Dateien mit unterschiedlicher Lebensdauer | Stetig steigende Anzahl an Dateien, lange Lebensdauer, Dateien eher größer bzw. verändern sich nicht |
| Wichtige Performancewerte |
|
|
|
Neben dem reinen effizientem Arbeiten eines Dateisystems spielt auch die Skalierbarkeit in puncto Verwaltung des Speicherplatzes und parallelem Arbeiten eine tragende Rolle. Paralleles Arbeiten von Dateioperationen kommt meisten im Zusammenhang mit großen Computersystemen vor, die viele Daten verarbeiten müssen. Damit dieser Bedarf an Datenübertragung erbracht werden kann, muss das Dateisystem möglichst gut Aufgaben in mehreren Prozessen oder Threads parallel bearbeiten und diese auf mehrere Prozessoren verteilen und verwalten können [82].
Um die Verwaltung des Speicherplatzes möglichst flexibel und damit skalierbar zu machen wird das Logical Volumen Management, kurz LVM, eingesetzt. LVM bildet eine Schicht die über mehrere Speichergeräte hinweg einen gemeinsamen Speicherbereich erzeugen und verwalten kann. Zu den Verwaltungsmöglichkeiten gehören Funktionen zum Hinzufügen und Entfernen von unterliegenden Speichergeräten und damit einem Vergrößern und Verkleinern des Speicherbereiches [83].
Die Optionen und Funktionsweisen des Verkleinerns und Vergrößerns einer Partition innerhalb dieses Speicherbereichs hängt vom verwendeten Dateisystem ab und muss gesondert geprüft werden. Nicht alle Dateisysteme erlauben generell das Vergrößern und Verkleinern, sowie das durchführen dieser Aktionen während die Partition im Zugriff ist [84] [85].
6.1.2 Sicherheit
Neben den Anforderungen an ein Dateisystem die sich durch die Hardware und benötigte Performance ergeben, werden heutzutage spezielle sicherheitsrelevante Anforderungen gestellt die sich aus dem Einsatzbereich ergeben. Grob lassen sich dabei die Anforderungen in die Kategorien für Betriebssicherheit und Zugriffsbeschränkung unterteilen. Anforderungen die sich aus dem Bereich der Betriebssicherheit ergeben, beziehen sich dabei überwiegend auf den Schutz vor Datenverlust und Erhalt der Datenintegrität. Um diesen Anforderungen gerecht zu werden, finden unter anderem die folgenden Techniken und Konzepte Verwendung:
| Journaling[86] | Journaling bedeutet das Führen einer Art Journal über Aktionen und Transaktionen die im Dateisystem durchgeführt werden. Ziel ist es den Zustand eines Dateisystems nach einem Systemcrash schnellstmöglich festzustellen und Fehler zu korrigieren, ohne alle Daten die im Dateisystem gespeichert sind auf ihre Konsistenz zu prüfen.
Alle Änderungen an Daten werden vor der Anwendung in das Journal geschrieben. In regelmäßigen Abständen werden diese Änderungen dann auf die Daten im Dateisystem angewendet. Sollte zwischen zeitlich ein Systemabsturz auftreten, kann anhand des Journals festgestellt werden welche Aktion zuletzt durchgeführt werden sollte/wurde. Journaling kann in drei Varianten realisiert sein:
|
| Snapshot[87] | Snaphots ermöglichen das Erstellen von konsistenten Datensicherungen ohne dabei das zu sichernde System in seiner Verfügbarkeit einzuschränken, wie dieses für das Durchführen einer konventionellen inkrementellen oder Vollsicherung der Fall wäre. Beim "Snapshotting" wird dabei zu einem definiertem Zeitpunkt eine "read-only" Kopie des kompletten Dateisystems bereitgestellt und bereitgehalten bis das Backup durchgeführt wurde. |
| RAID-Technologie[88] | Für die Sicherstellung der Datenverfügbarkeit sind aus dem Bereich RAID-Technologie die Varianten von Bedeutung, die Daten redundant auf mehreren Datenträgern organisieren oder anstelle von redundanten Daten mit Paritätsinformationen arbeiten.
Beispiele sind die Raid-Funktionen von ZFS[89] und BtrFS[90]. |
| Checksummen | Zur Sicherstellung der Integrität der Daten im Dateisystem werden Checksummen für die Daten erstellt. Bei eine Itegritätprüfung kann die Datei nun anhand der Checksummen geprüft werden [91]. |
| Versionierung | Änderungen an Daten werden so abgebildet, dass sich zu einem späteren Zeitpunkt die unveränderten Daten wieder abrufen lassen. In den meisten Fällen ist dies so realisiert, dass geänderte Daten die Original-Daten nicht überschreiben solange ausreichend freie Speicherplatz zur Verfügung steht um die geänderten "Kopien" dort abzuspeichern [92]. |
Im Bereich der Zugriffsbeschränkung geht es um die Sicherstellung, dass nur autorisierte Personen oder Dienste Zugriff auf Daten erhalten die für sie bestimmt sind, wie dies beispielsweise nach Sarbanes-Oxley Act (kurz SOX) gefordert wird. Zur Sicherstellung dieser Anforderung werden unter Anderem die folgenden Techniken und Konzepte verwendet:
| Dateisystemrechte für Benutzer und Gruppen nach POSIX | Unterstützung der Vergabe von Rechten auf Dateien nach dem POSIX-Standard ("Unix-like"). Jede Datei gehört einem Benutzer und einer Gruppe. In Abhängigkeit zum Benutzer, der Gruppe und Personen die weder der Eigentümer noch Gruppenmitglied sind können Lese-, Schreib- oder Ausführrechte vergeben werden [93]. |
| Access Control Lists (kurz ACL) | ACLs erweitern das Konzept Rechteverwaltung auf Datei- und Verzeichnisebene, wie sie beispielsweise von "Unix-like" Betriebssystemen bekannt ist[94], und erlaubt den Aufbau von komplexeren Sicherheitseinstellungen. ACLs müssen vom Betriebssystem und dem Dateisystem unterstützt werden [95], wobei der Funktionsumfang von Betriebssystem und Dateisystem abhängt. Unter NTFS und Microsoft Windows werden über die ACL-Eigenschaften ebenfalls die Richtlinien zum Audit von Dateizugriffen gesteuert [96]. |
| Datenverschlüsselung | Anforderungen zur Verschlüsselung von Daten auf Medien steigt und wird beispielsweise für Regierungseinrichtungen der Vereinigten Staaten von Amerika empfohlen [97] [98].
Unterschieden werden muss dabei zwischen Teilverschlüsselung auf Basis von Dateien und Verzeichnissen und der Vollverschlüsselung eines Dateisystems. |
| Sicheres Löschen | Löschen von Daten stellt ein Risiko dar, falls diese Daten permanent gelöscht werden sollen, da diese in der Regel nicht aus dem Dateisystem gelöscht werden, sondern nur aus dem Zugriff entfernt werden. Der belegte Speicherplatz würde dann bei Bedarf wieder überschrieben werden. Um dieses zu vermeiden könnte beispielsweise das Konzept genutzt werden diese Bereiche mehrfach gezielt mit neuen Daten zu überschreiben[99]. |
6.2 Eignung moderner Dateisysteme für magnetische, optische und elektrische Datenträger
6.2.1 ZFS
6.2.1.1 Name und Ursprung
ZFS ist ein Dateisystem von SUN Microsystems, welches aktuell für die Betriebssysteme FreeBSD, Mac OSX und Solaris für den produktiven Einsatz im professionellen Umfeld freigegeben ist. ZFS ist die Abkürzung für Zetta-File-System und soll die Unbeschränktheit des Dateisystems bezüglich der Maße zu verwaltender Daten unterstreichen [100]. Die Entwickler entwarfen ZFS mit dem Ziel, ein robustes, skalierbares und einfach zu administrierendes Dateisystem bereitzustellen. [101].
ZFS verwaltet einzelne oder mehrere Datenträger zusammen in Storage Pools. Es wird absichtlich auf die Spezifikation von Datenträgertyp und Systemanbindung verzichtet, um zukünftige Entwicklungen nicht zu behindern. Trotzdem beschränkt sich die aktuelle Nutzbarkeit auf magnetische Festplatten und elektrische Datenträger[102].
Als erstes Dateisystem ist es auf den Einsatz von Solid State Disks optimiert worden (siehe Hybrid Storage Pools)[103].
6.2.1.2 Verwendung und Einsatzgebiete
ZFS wurde mit dem Betriebssystem Solaris 10 in Update 4 für den professionellen Einsatz freigegeben. Die aktuelle Version von Solaris (10 Update 6) ermöglicht nun das Booten des Betriebssystems aus einem ZFS-Pool [104]. ZFS wird das bisherige Standarddateisystem von Solaris ablösen [105]. Neben Solaris wird ZFS ebenfalls von den Betriebssystemen Mac OSX Server und FreeBSD. Mit zfs-fuse kann ZFS ebenfalls unter Linux eingesetzt werden. Ein nativer Einsatz von ZFS außerhalb von Solaris wird von SUN durch die Verwendung einer eigenen Lizenzierung verhindert.
6.2.1.3 Allgemeine Eigenschaften
Historisch wurden Dateisysteme für die Verwaltung eines einzelnen Datenträgers konstruiert. Um mehrere Datenträger adressieren zu können, sowie Redundanz und Ausfallsicherheit bereitzustellen, mussten zusätzliche Volume Manager eingesetzt werden, welche die Datenträger zusammenfassen und dem Dateisystem als eine Einheit zur Verfügung stellten. Mit Hilfe des "Storage-Pool"–Konzeptes verbindet ZFS das klassische Dateisystem mit einem voll integrierten Volume Manager. Die zur Verfügung stehenden Festplatten werden hierzu in einem oder mehreren Storage Pools organisiert und dem Administrator zur Verfügung gestellt. Damit entfällt die Verwaltung einzelner Datenträger. [106].
Wie jeder moderne Volume Manager unterstützt ZFS die grundlegenden Spiegelungs-, Striping- und Snapshotmechanismen, sowie die Möglichkeit, Datenträger als Hot Spares zu kennzeichnen. Zur Kompression einzelner Volumes und Snapshots können LZJB und GZIP eingesetzt werden [107].
ZFS ist ein transaktionales Dateisystem und garantiert durch seine Funktionalität, dass der Dateisystemstatus auf jedem Datenträger zu jeder Zeit konsistent ist [108]. Zur Sicherstellung der Datenintegrität bildet ZFS Prüfsummen über Daten und Metadaten. Darüber hinaus bietet ZFS eine Selbstheilungsfunktion, welche defekte Daten erkennt und diese von einer Spiegelplatte wiederbeschafft [109].
ZFS beruht auf einer 128-Bit-Architektur und ist in der Lage, bis zu 256 Billiarden Zettabyte zu sichern. Da die Metadaten dynamisch zugewiesen werden, entfällt die Restriktion durch einer beschränkten Inode-Tabele [110].
6.2.1.4 Medientyperkennung
ZFS ist in der Lage, den angesteuerten Medientyp zu erkennen und die Handhabung des Medientyps auf diesen zu optimieren. Durch die Vergabe von Attributen beim Einrichten eines Dateisystems ist es möglich, unterschiedliche Medien derart zu kombinieren, dass sie für das Dateisystem optimal eingesetzt werden können. So können teurere, aber schnellere Solid State Disks als Zwischenspeicher beim Laden von Festplatte genutzt werden, womit der Gesamtdatendurchsatz erhöht wird. Im Gegensatz zu anderen Lösungen, ist ZFS zusätzlich speziell auf die Verwendung von Intel SSDs spezialisiert worden, welche intern ein proprietäres Dateisystem einsetzen [111].
6.2.1.5 Hybrid Storage Pools
Magnetische Datenträger sind heute die kostengünstigsten und größten Datenspeicher. Sie sind allerdings weitaus langsamer als elektronische Datenträger (siehe Kapitel 5 - Datenträger). ZFS kombiniert beliebig angeschlossene Datenträger, mit Hilfe der Medientyperkennung oder frei konfigurierbar, in einem Hybrid Storage Pool Solid State Disks. Solid State Disks werden dabei entweder allgemein als Data Cache oder für spezielle, aktiv genutzte Daten zwischen Hauptspeicher und Festplatten eingesetzt und ermöglichen so einen wesentlich höheren Gesamtdurchsatz. ZFS verwaltet diese Funktionalität intern, weshalb Hybrid Storage Pools für das Betriebssystem und die Applikation transparent bleiben.[112]
Abbildung 8: ZFS - Hybrid Storage Pools[113]
|
6.2.1.6 RAID-Z
ZFS stellt durch die Funktionalität von RAID-Z Dateisysteme mit einer Fehlertoleranz einfacher oder doppelter Parität zur Verfügung. Bei RAID-Z ist die einfache Parität mit RAID-5, die Doppelte entsprechend mit RAID-6 vergleichbar.
Im Gegensatz zu den herkömmlichen Verfahren kann eine RAID-Z-Konfiguration gleicher Sicherheitsstufe wie RAID-5, also mit einfacher Parität, bereits mit zwei, RAID-6 mit drei, Datenträgern aufgebaut werden. ZFS unterteilt dabei die Festplatten in Daten- und Paritätspartitionen. ZFS sichert die Daten auf einen der beiden Datenträger und schreibt die Parität auf den anderen.[114]
Wie bei den herkömmlichen RAID-Verfahren erhöht sich die Wiederherstellungssicherheit durch die Verteilung der Paritäten auf mehrere Datenträger[115].
6.2.2 XFS
6.2.2.1 Name und Ursprung
Die Entwicklung von XFS wurde durch die Firma Silicon Graphics Inc., kurz SGI, 1993 gestartet, mit dem Zweck für die Workstation und Server von SGI das Dateisystem der "nächsten Generation" zu sein. Die erste stabile Version wurde im Dezember 1994 mit der Version 5.3 von SGI's Unix Derivat IRIX ausgeliefert, das Standarddateisystem unter IRIX wurde es allerdings Anfang 1996 mit IRIX 6.2 [116].
6.2.2.2 Verwendung und Einsatzgebiete
Bis zum Jahr 2000 war XFS nur für das Betriebssystem IRIX verfügbar und konnte damit überwiegend nur auf Systemen von SGI eingesetzt werden, was die Verbreitung stark einschränkt. Im März 2000 wurde der Source Code von XFS unter der General Public License von SGI veröffentlicht[117] und die Version 1.0 von XFS für Linux wurde im Mai 2001 fertig gestellt. Anschließend fand XFS eine schnelle Verbreitung und Unterstützung in den gängigen Linux Distributionen, wie Mandrake, SuSE und Debian, und damit auch im kommerziellem Linuxumfeld[118]. Die Verbreitung zum Stand Mai 2009 von XFS erstreckt sich von der Unterstützung in der Standardinstallation aller größeren Linuxdistributionen (bis auf Redhat) über Speichersystemprodukte, einer viel Zahl von Bildungs-/Forschungseinrichtungen bis hinzu kommerziellen Nutzung in Firmen[119]. Nach Angaben von SGI ist XFS ausgelegt für den Einsatz in Umgebungen die hohe Ansprüche an Speicherbedarf, Performance und Skalierbarkeit haben[120]. Zu diesen Umgebungen gehören beispielsweise Anbieter von Video-On-Demand Diensten[121]
6.2.2.3 Allgemeine Eigenschaften
XFS ist ein vollständiges 64-Bit Journaldateisystem und besitzt daher Eigenschaften zur schnellen Wiederherstellung nach Systemabstürzten und kann bis zu 9 Exabyte Adressraum verwalten[122]. Neben diesen Grundeigenschaften bietet es Unterstützung für Disk Quotas, Zugriffskontrolllisten (ACL) und Volumen Manager. Eine Besonderheit von XFS ist der durchgängige Einsatz von B+Bäumen zur Optimierung der Skalierbarkeit zur Verwaltung von Verzeichnisinhalten. Durch die Nutzung von B+Bäumen wird beispielsweise der Zugriff auf spezielle Dateien erheblich beschleunigt, im Vergleich zu Systemen die einen linearen Lookup durchführen müssen. Darüber hinaus soll XFS einen hohen Datendurchsatz durch konsolidierte parallele I/O-Anfragen und die Nutzung von Direct Media Access (DMA) ermöglichen[123].
6.2.2.4 Speichertechnologie
XFS ist durch die Zeit und dem geplanten Einsatzbereich für Speichersysteme entwickelt worden die auf magnetischen Festplatten beruhen[124]. Dementsprechend wurde und wird bei der Entwicklung von XFS durchgängig die Prämisse verfolgt Seeking-Operationen zu minimieren, was durch ein intelligentes Allozieren von Plattenspeicherplatz erreicht werden soll[125]. Dementsprechend finden sich in den Lese- und Schreibfunktionen von XFS spezielle Methoden zum Allozieren von Blöcken auf der Festplatte, die so implementiert wurden, dass das tatsächliche Allozieren nicht mehr auf dem kritischen Pfad für einen Schreib- oder Lesevorgang liegt und somit die Geschwindigkeit weniger beeinflussen kann[126]. Das Allozieren erfolgt aus diesem Grund erst im Hauptspeicher, in dem die Daten gesammelt werden, und zu einem späteren Zeitpunkt wird der gesamt benötigte Speicher auf der Festplatte alloziert[127].
Weitere Optimierungen bauen auf diesen Funktionen auf, wie beispielsweise die Vermeidung der Fragmentierung von Dateien, was zur Folge eine geringere Anzahl an I/O-Request hat[128]. Neben der Vermeidung von Seeking besitzt XFS eine gute Skalierbarkeit hinsichtlich seinem Laufzeitverhalten in mehreren Threads[129].
In XFS ist bisher keine direkte Optimierung für Solid State Disks eingeflossen. Eine Möglichkeit um XFS für diese Speichertechnologie zu optimieren, sehen die Entwickler in der Unterstützung des in die aktuelle SSD-Controller integrierte "intelligente" Verwaltung von ungenutzten Blöcken. Um eine einheitliche Unterstützung bieten zu können wurde daher in den Linux Kernel ab Version 2.6.30rcX die Funktion blkdev_issue_discard() integriert, die entsprechend von dem Dateisystem genutzt werden muss[130].
6.2.3 NTFS
6.2.3.1 Name und Ursprung
NTFS wurde von Microsoft im Juli 1993 zusammen mit dem Betriebssystem Windows NT 3.1 veröffentlicht. Die Abkürzung NTFS steht für New Technology File System. NTFS ist eine Weiterentwicklung des High Performance File Systems (HPFS), dass Ende der achtziger Jahre zusammen von IBM und Microsoft entwickelt wurde[131].
6.2.3.2 Verwendung und Einsatzgebiete
NTFS wird fast ausschließlich auf Windows Systemen eingesetzt. Es gibt einige Windows Funktionen die einen NTFS Datenträger voraussetzen. Ohne die Verwendung von zusätzlichen Treibern lässt sich ein in NTFS formatierter Datenträger nicht unter anderen Betriebssystemen einsetzen. Für Linux und einige weitere Betriebssysteme wurde der als freie Software erhältliche Treiber ntfs-3g entwickelt. Der mittlerweile als stabil geltende Treiber ermöglicht das Einbinden von NTFS Datenträgern, sowohl für den lesenden als auch schreibenden Zugriff. Der Zugriff auf verschlüsselte und komprimierte Dateien ist in der aktuellen Version vom 4. April 2009 nicht möglich. Ebenso fehlt derzeit noch die Möglichkeit Zugriffsrechte auf Dateien und Ordner zu verändern[132] [133].
6.2.3.3 Allgemeine Eigenschaften
NTFS ist ein transaktionales Dateisystem. Das bedeutet, dass ähnlich wie bei einer Datenbank alle Informationen zu Veränderungen an Verzeichnissen und Dateien in einem Logfile protokolliert werden. Ist eine Transaktion erfolgreich durchgeführt, so wird dies ebenfalls im Logfile protokolliert. Bei Abbruch einer Transaktion bspw. durch einen Hardware Fehler oder einem Programmabsturz, werden die im Rahmen der Transaktion zuvor getätigten Schritte vollständig rückgängig gemacht[134]. Das NTFS speichert zu jeden Datensatz Informationen in der Master File Table (MFT). Ein Datensatz umfasst unter anderem Zeitstempel, Verbindungszähler, Dateinamen, Sicherheitsberechtigungen und die Daten selber. Bis zu einer Dateigröße von ca. 1.500 Byte werden diese Informationen komplett in der MFT abgelegt. Man spricht dabei von residenten Dateien. Der Zugriff auf diese Dateien ist i.d.R. wesentlich schneller als auf nicht residente Dateien. Datei die größer als 1.500 Byte sind werden auf weitere Speicherbereiche ausgelagert. Innerhalb des Datensatzes in der MFT wird dann auf die Speicherbereiche verwiesen[135]. Der Aufbau des Dateisystems ist sehr flexibel. Lediglich der Bootsektor hat eine feste Position auf dem Laufwerk. Alle anderen Metadaten wie beispielsweise die Master File Table (MFT) und die Sicherheitskopie der MFT haben keine festen Positionen. Für die MFT wird während der Formatierung ein Bereich von ca. 12,5% der Laufwerksgröße reserviert, der nicht von anderen Dateien belegt werden kann[136]. Überschreitet die Größe der MFT den reservierten Speicherbereich von 12,5% wird freier Speicher auf dem Laufwerk verwendet und die MFT verteilt sich über mehrere nicht zusammenhängende Bereiche, was die Performanz des Laufwerks nachteilig beinflusst[137]. NTFS erkennt fehlerhafte Sektoren auf der Festplatte und leitet Schreibvörgange auf diese Sektoren in einen anderen Bereich um. Die entdeckten fehlerhaften Sektoren werden in der Datei $BadClus referenziert[138]. | Abbildung 9: Schematischer Aufbau
eines NTFS-formatierten Datenträgers[139] |
6.2.3.4 Speichertechnologie
Die beschriebene Protokollierung hat für die Konsistenz der Daten einen offensichtlichen Vorteil, gleichzeitig bedeutet sie aber auch eine höhere Belastung des Datenträgers an bestimmten Positionen. Im Hinblick auf die vorgestellten Speichertechnologien wird nun deutlich, dass sich NTFS nicht für jede Art von Datenträgern eignet. Der Einsatz auf optischen Datenträgern ist z.B. besonders schlecht.
Neben den bereits vorgestellten Funktionen bietet NTFS eine Reihe weiterer Funktionen beispielsweise für die Wiederherstellbarkeit, Verschlüsselung und Sicherheit von Daten, die aber hinsichtlich der zu verwendenden Speichertechnologien kaum Einfluss haben und auf die daher an dieser Stelle nicht weiter eingegangen wird.
6.2.4 BtrFS
6.2.4.1 Name und Ursprung
BtrFS [gesprochen: better File System] ist ein Dateisystem das primär für ein Betriebssystem der Linuxfamilie entwickelt wird und nach dem "copy on write" Prinzip/Verfahren arbeitet. Ziel der Entwickler von BtrFS ist es ein Dateisystem zu entwickeln welches ein hohes Maß an Skalierbarkeit und Fehlertolerant besitzt, große Datenträger unterstützt und trotzdem einen speicherplatzeffizienten Umgang mit kleinen Dateien bietet [140] [141]. Die Entwicklung befindet sich aktuell noch in einem sehr frühen Stadium und wird, nachdem Oracle das Projekt gegründet hat, nun von einem Team aus freien Entwicklern unter der "General Public License" weitergeführt.
6.2.4.2 Verwendung und Einsatzgebiete
Die Verbreitung von BtrFS ist sehr gering, da es erst am 09.01.2009 in den experimentellen Zweig des Linux-Kernels 2.6.29 aufgenommen wurde und bis dato noch keine der größeren Linux-Distributionen, vor allem keine Enterprise-Distribution, diesen Kernel mitliefert.
6.2.4.3 Allgemeine Eigenschaften
Da BtrFS als ein potenzieller Nachfolger der freien Dateisysteme ext3 und ext4 gesehen werden und auch kommerziellen Systemen in nichts nachstehen soll, liegt der Fokus auf Funktionen die Stabilität und Effizienz steigern, sowie vom Einsatzbereich im Enterprise-Bereich gefordert werden (siehe Optimierte Dateisysteme - Anforderungen).
Zu diesen Funktionen gehören unter Anderen die Unterstützung von Snapshots, Subvolumes (bis zu 2^64 ), Kompression, Spiegelungs- und Stripingmechanismen, Checksummen für Daten und Metadaten, Online Dateisystemprüfung, Online Dateisystemdefragmentierung [142].
Zusätzlich wurde bei dem Design von BtrFS die Option der Konvertierung von ext3- (ggf. ext4-) Volumes in BtrFS-Volumes berücksichtigt, was durch das "copy on write"-Verfahren, die festen Bereiche der Metadaten und dem Referenzieren auf durch das ext3- (ggf. ext4-) Dateisystem verwendeten Blöcken möglich ist. Änderungen an Daten nach der Konvertierung werden ausschließlich in freien Speicherbereichen durchgeführt, bis der Administrator die Konvertierung als endgültig bestimmt. So lange dies nicht geschieht bleiben alle ext3 (ggf. ext4) zugehörigen Daten erhalten und die Konvertierung kann jeder Zeit rückgängig gemacht werden [143]
6.2.4.4 Speichertechnologie
BtrFS besitzt eine eigene Schicht zur Geräteverwaltung und bietet damit eine Abstraktionsschicht für den einheitlichen Zugriff auf Hardwareressourcen an, die fast durchgängig vom Dateisystem genutzt wird [144]. Dabei ist BtrFS in der Lage über mehrere Geräte hinweg eingesetzt zu werden. Bei diesem Vorgehen können die Metadaten über die vorhandenen Geräte gespiegelt und die Daten über die diese verteilt werden, in Abhängigkeit der gewählten Methode (z.b. Mirroring, Striping). Die Funktion der Datenspiegelung muss dabei nicht über zwei Geräte erfolgen, sondern kann ab einem Gerät eingesetzt werden. Der Vorteil zeigt sich in dem Fall des Auftretens von korrupten Daten. Korrupte Daten werden von BtrFS durch Checksummen erkannt und wenn verfügbar die korrekte Kopie der Daten vom Spiegelpartner gelesen. Die Spiegelpartner müssen nicht von identischer Größe sein. Das Hinzufügen und Entfernen von Geräte aus dem Volume kann dabei im Online-Zustand der Volumes erfolgen [145].
Durch "Extended Block Groups" ist es möglich ein mit BtrFS formatierten Datenträger in Einheiten zu 256MiB aufzuteilen. Jede "Extended Block Group" wird dabei per Schalter markiert, ob diese für die Speicherung von Metadaten oder Daten verwendet wird. Bei der Einrichtung eines BtrFS erfolgt eine Aufteilung des Speichers des Datenträgers, bei dem 33% für die Speicherung von Metadaten und 66% für Daten vorgesehen sind. Die für Metadaten und Daten verwendeten "Extended Block Group" werden nicht gemischt auf dem Datenträger gespeichert, sondern immer erst die Metadaten und nach dem Metadatenbereich die Daten, auch wenn diese eine Reorganisation der "Extended Block Group" auf dem Datenträger bedeuten würden, einschließlich einer Änderung des 1 zu 2 Verhältnisses der Daten/Metadaten "Extended Block Groups". Daraus ergibt sich der Vorteil der Reduktion von Seek-Vorgängen auf dem Datenträger und damit auch eine Verringerung der Einlesezeiten der Metadaten nach einem Systemabsturz [146].
Neben der Minimierung der "Seek"-Vorgänge wurde BtrFS auch für Solid State Disks optimiert, wobei die Optimierungen noch explizit aktiviert werden müssen. Für die fertige Version werden die Optimierungen zu den Standardoptionen gehören [147]. Die Optimierung basiert dabei auf dem Prinzip möglichst Schreibzugriffe auf die Solid State Disk von Metadaten und Daten (unabhängig ob diese zu einem speziellem Verzeichnis gehören) zusammenzufassen, was durch das "copy on write"-Verfahren ermöglicht wird. Zusätzlich wird die Optimierung zur Reduzierung von "Seek"-Vorgängen reduziert, da es bei Solid State Disks kein Seeking gibt wie bei herkömmlichen Festplatten [148] [149].
6.2.5 ISO 9660 - das CDFS
6.2.5.1 Name und Ursprung
1987 veröffentlichte die Electronical Component Manufacturer Association (ECMA) eine zweite Version ihres Standards ECMA-119: "Volume and File Structure of CDROM for Information Interexchange" und übermittelte diesen an die International Standard Organisation (ISO). Die ISO bestätigte den vorgeschlagenen Standard im Folgejahr als ISO-9660:1998 [150].
Der Standard wurde von diversen Hardware- und Softwareherstellern zur Adaption der CDROM für den Datenaustausch am Computer entwickelt und beschreibt das Wesen eines Dateisystems auf einem einmalig beschreibbaren Medium[151], respektive einer einzelnen Spur einer Audio-CD: der Spur 0.
6.2.5.2 Verwendung und Einsatzgebiete
Durch ihre lediglich einmalige Beschreibbarkeit ist die CDROM heute noch das wichtigste transportable Medium für Daten und Audio und vor allem bei Software- und Musikherstellern beliebt.
Durch seine historische Entwicklung ist ISO9660 für alle Computerbetriebssysteme verfügbar. Obwohl heute meist nicht mehr direkt und ausschließlich im Einsatz, wird ISO9660 immer noch zu Kompatibilitätszwecken mitgeschrieben. Heute sind vor allem die Dateisysteme JOLIET, die Unicode-Erweiterung des ISO9660 von Microsoft[152], und ROCKRIDGE[153] für Unix-basierte Betriebssysteme im Einsatz. Diese Dateisysteme können allerdings nicht gemeinsam auf einer CDROM genutzt werden, weshalb sie das ISO9660 zu Kompatibilitätszwecken einsetzen.
6.2.5.3 Eigenschaften
Wie FAT ordnet ISO9660 seine Daten in einer Baumstruktur ab, welche in einem speziellen Speicherbereich am Anfang der CDROM abgelegt wird[154].
Grundsätzlich können 3 Restriktionsstufen von ISO9660 unterschieden werden:
- Obwohl Level 1 die restriktivste Form von ISO9660 ist, ist diese doch auch diejenige, welche in ECMA-119 beschrieben wurde und welche von allen Computerbetriebssystemen unterstützt werden muss. Level 1 beschränkt die Baumtiefe auf 8 Stufen. Die maximale Länge der Dateinamen beträgt 8 Zeichen, wobei diese um eine 3-Zeichen-Endung erweitert werden[155].
- Level 2, ebenfalls bereits in ISO9660 definiert, schränkt lediglich noch die Länge der Dateinamen und Verzeichnisnamen auf 31 Zeichen ein. Die Einschränkung auf eine maximale Pfadtiefe von 8 fällt weg.
- Level 3 hat keine derartigen Einschränkungen an Dateinamen und Pfadtiefe mehr[156].
Um zusätzliche Daten über die enthaltenen Informationen festhalten zu können, nutzt ISO9660 den Mechanismus erweiternder Attribute für Pfad- und Dateieinträge. Mit Hilfe dieser Attribute lassen sich zusätzliche Informationen wie echter Erstellungszeitpunkt, Modifikationszeitpunkt, Ablaufzeitpunkt und Berechtigungen aufzeichnen, welche unterschiedlich zum Übertragungszeitpunkt auf den Datenträger sein können[157].
6.2.6 UDF - Das Universal Disk Format
6.2.6.1 Name und Ursprung
Das Universal Disk Format ist ein Dateisystem, welches für den Einsatz auf optischen Medien entwickelt und durch die Optical Storage Technology Association (OSTA) betreut wird. 1996 stellt die OSTA mit Version 1.02 den ersten, kommerziell genutzten, Standard vor, welcher bis heute das Standarddateisystem der DVD, der Blu Ray und der HVD beschreibt[158].
UDF ist ein offener Standard. Die verwendeten Datenstrukturen und Algorithmen wurden in ECMA- 167 und ISO/IEC 13346:1995 beschrieben und zertifiziert[159].
| Revision | Publikationszeitpunkt | Wichtigste Neuerung |
| 1.02 | 08.1996 | Erste Version, für Readonly Medien |
| 1.50 | 02.1997 | Unterstützung für Write-Once Medien und Fehlerbehandlungsmanagement auf Medien |
| 2.00
2.01 | 04.1998
03.2000 | Unterstützung für Named Streams
Kleinere Fehlerkorrekturen am UDF |
| 2.50 | 04.2003 | Metadatenpartition für Performanceverbesserung eingeführt |
| 2.60 | 03.2005 | Unterstützung für Pseudo-Überschreibung für ReadWrite-Medien |
6.2.6.2 Verwendung und Einsatzgebiete
Wie der Name schon sagt, kann UDF für alle nicht-sequenziellen Datenträger verwendet werden. Hierbei ist es in der aktuellen Revision unerheblich, ob es sich um einen optischen, magnetischen oder elektronischen Datenträger handelt oder ob der Datenträger nur gelesen, einmal beschrieben oder mehrfach wiederbeschrieben werden kann[161]. Hauptaugenmerkt lag bei der Definition von UDF auf der Verwendung in transportablen Datenträgern und ihren Einsatz in unterschiedlichen Plattformen und Betriebssystemen. [162]
Die heutige Verbreitung von UDF beschreibt vor allem die weltweite Verbreitung der Revision 1.02 von UDF als Standarddateisystem der Video-DVD. Die aktuelle Revision, 2.60, wird bisher ausschließlich vom aktuellen Linux – Kernel unterstützt. Revision 2.50 ist sowohl in Microsofts Windows Vista und in Apple Mac OSX 10.5 implementiert worden[163].
6.2.6.3 Allgemeine Eigenschaften
UDF verwaltet Partitionen mit einer Größe bis zu 8 Terabyte bei einer Blockgröße von 2KB. Bei Verwendung der Mindestblockgröße, welche gleichzeitig Standard ist, verwaltet UDF Partitionen bis 2 Terabyte[164].
Wie alle aktuellen Dateisysteme, kann auch UDF übergroße Dateien (64-bit Länge) adressieren. Hierbei kann der Dateiname maximal 255 Zeichen lang sein, wobei UDF die 8-bit Unicode Zeichencodierung für die Dateinamen verwendet. Zusätzlich besteht bei UDF die Möglichkeit, Hard und Softlinks zu verwenden[165].
6.2.6.4 Metadaten und Checksummen
Zur Verbesserung der Performance beim Lesen und Schreiben von Datenträger, wurde mit der Revision 2.50 ein Metadatenverzeichnis in Form einer Metdatenpartition eingeführt[166]. Das Verzeichnis enthält die Dateinamenzuordnung, Blockzuordnungen und die Verzeichnisstruktur, nicht jedoch die erweiterten Attribute oder die Named Streams[167].
6.2.6.5 Standard und Erweiterte Attribute
Die verwendeten Standard-Attribute zeigen die Nähe von UDF zu Unix Dateisysteme. So werden auch bei UDF der Dateityp, UserID, GroupID, zugehörige Berechtigungen, Dateilink-Zähler, Aufzeichnungsformat und –länge, Informationslänge, sowie die letzten Bearbeitungszeiten und Zugriffszeiten mit aufgezeichnet[168]. Mit Revision 2.50 wurden diese Attribute ins Metadatenverzeichnis aufgenommen.
Mit den erweiterten Attributen werden dem Betriebssystem zusätzliche Informationen über die Datei übermittelt. So erweitert man die Datumsinformationen zusätzlich um die Zeitpunkte des erstmaligen Erstellens und der letzten Sicherung der Datei. Für die Informationen in der Datei sind Erstelldatum, letzter Bearbeitungszeitpunkt und Verfallszeitpunkt spezifizierbar. Die zusätzlichen Berechtigungen ermöglichen die Definition mehrerer Benutzer mit unterschiedlichen Rechten. Außerdem sind die zu verwendende Applikation und Implementierung definierbar[169].
6.2.6.6 Betriebssystem-Kompatibilität
Der Standard von UDF verpflichtet das Dateisystem, sich auch mit den Eigenheiten einiger Betriebssysteme und Betriebssystemarten direkt zu beschäftigen. So werden zu jedem Element, welches innerhalb des UDF gespeichert werden, spezielle Attribute für den Mac OSX Finder, den Windows Explorer und die Unix ACL-Implementierung mitgeführt[170].
6.2.6.7 Named Streams
Wie die Dateiattribute bieten auch Named Streams Mechanismen zum Auffinden von Daten in einem UDF. Im Gegensatz zur Verwendung von Standard- und erweiterten Dateiattributen, haben Named Streams keine Größenbeschränkung. Sie zeigen sich, ähnlich den RAW-Dateien, nach Außen als eine einzelne Datei, der Inhalt und die Verwaltung des Inhalts wird der Applikation überlassen. Dies kommt vor allem Datenbanken mit eigenen Dateisystemen zu Gute. Da Named Streams in den Metadaten gesondert ausgeschrieben werden, ist das Auffinden ihres Startblocks noch einmal wesentlich schneller als normale Dateien, da nicht das gesamte Metadatenverzeichnis durchsucht werden muss[171].
6.2.6.8 Pseudo Overwrite (POW) Verfahren
Bis Revision 2.50 nutzte UDF ausschließlich das Multi-Session- und Virtual-Allocation-Table Verfahren, um mehrfaches sequenzielles Schreiben zu ermöglichen. Das System sucht beim Einlesen des Datenträgers nach der letzten, aktuellsten VAT und liest auf Basis dieser Daten die Dateien vom Datenträger ein.
Die Metadaten- und POW-Unterstützung ermöglicht, dass alle logischen Zuordnungen überschrieben werden können. Das Dateisystem kann dabei gleichzeitig mehrere Tracks beschreiben, wobei unbenutzte Tracks weiterhin zuerst sequenziell beschrieben werden, vollständig beschriebene Tracks als "USED" markiert und anschließend variabel überschrieben werden können. Die Metadatenpartition enthält dabei den aktuellen Zustand des Datenträgers[172].
6.2.7 JFFS / JFFS2
6.2.7.1 Name und Ursprung
JFFS (Journaling Flash File System) bzw. sein Nachfolger JFFS2 sind spezialisierte Dateisystem, die für den Einsatz auf Flashspeichern konzipiert wurden. Dieses Dateisystem setzt nicht auf anderen Dateisystemen auf sondern arbeitet direkt auf den Flashbausteinen. Bei JFFS2 handelt es sich um ein Log-Structured-Dateisystem, bei dem das Journaling nicht auf Dateisystem aufgesetzt wird, sondern das notwendige Logging für die eigentliche Dateisystemorganisation genutzt wird. Entwickelt wurde JFFS ursprünglich von dem schwedischen Unternehmen Axis Communications AB, welches dann von Red Hat zu JFFS2 weiterentwickelt wurde[173].
6.2.7.2 Verwendung / Einsatzgebiete
JFFS/JFFS2 wird hauptsächlich in Linux-Umgebungen eingesetzt. JFFS2 wurde Bestandteile des Linux Kernels mit der Version 2.4. Beide Dateisysteme wurden für den Bereich der Flashspeichertechnologie entwickelt. Aufgrund fehlender Fehlerkorrekturverfahren war JFFS nur für NOR-Flash geeignet. JFFS2 ist hingegen prinzipiell auf für den Einsatz auf NAND-Flash vorgesehen[174].
6.2.7.3 Eigenschaften
6.2.7.3.1 Log-Structured
Ein Log-Structured-Dateisystem schreibt alle Änderungen der Daten und der Metadaten sequentiell in einer Log-ähnlichen Form auf den Datenträger. Dies soll sicherstellen, dass neben den Nutzdaten auch parallel alle Informationen, die im Falle eines Crashs zur Fehlerbehebung gebraucht werden, zur Verfügung stehen. Somit gibt es nicht wie bei bisherigen Dateisystemen eine Datenhaltung mit aufgesetztem Journaling, sondern das logbasierte Schreiben der Daten ist die einzige Form der Datenhaltung auf dem Datenträger[175].
Der Log besteht aus einer verketteten Liste von Knoten. In den meisten Fällen repräsentiert so ein Knoten einen Teil einer Datei in Form einer Inode. Wenn der Datenträger unter Linux gemountet wird, scannt das System zunächst alle Knoten und baut daraus zwei Datenstrukturen auf. Eine Struktur ist eine Hashtabelle, die eine Verknüpfung der Inoden mit dem aktuellen Stand auf dem Flashspeicher herstellt. Die andere Struktur ist eine Liste der gültigen Inoden, die auf dem Flashspeicher persistent gespeichert worden sind. Mittels dieser Technik kann die Datenhaltung auf dem Flashspeicher relativ einfach gehalten werden, da die Struktur des Datenträgers bereits im Hauptspeicher verfügbar ist. Somit braucht keine Mapping oder Indexinformation beim Schreiben von Daten auf dem Flashspeicher mitgeführt werden. Dies führt zu einer verbesserten Performance aber auch zu einem größeren Verbrauch an Arbeitsspeicher[176].
Log-Structured-Dateisystem basieren auf der Annahme, dass Schreibzugriffe aus Sicht der Performance mehr in den Vordergrund rücken, da Lesezugriffe meist schon durch intelligente Caching-Mechanismen und größere Mengen an Hauptspeicher reduziert werden. Bedingt durch die Tatsache, dass die Daten nun nur sequentiell in ein "Log" geschrieben werden, kann die Performance der Schreibzyklen enorm gesteigert werden, da nicht erst gesucht werden muss, an welcher Stelle die Daten abgelegt wurden. Ebenso ist ein Auswerten der Loginformationen nach einem Systemcrash weitaus einfacher, da nicht erst der gesamte Datenträger nach Loginformationen durchsucht werden muss. Es reicht, wenn der zuletzt geschriebene Teil des Logs gelesen und ausgewertet wird. Außerdem erhöht sich Performance auf Flashspeichern da die notwendigen, langsamen Löschzyklen, die vor dem (Wieder)-Beschreiben eines Sektors notwendig sind, entfallen[177].
Problematisch ist die Tatsache, dass für solche ein simples Fortschreiben der Daten stets genügend Speicher auf dem Datenträger frei sein muss. Schließlich werden die Daten redundant auf dem Medium abgelegt und stets die letzte Version gilt als einzig gültiger Stand. Ältere Versionen sind dann hinfällig und verbrauchen unnötig Speicherplatz. Dazu muss eine Art Garbage Collection diese unnötig belegten Speicherplätze wieder freigeben. Ziel ist es, am Kopf des Logs den ältesten Bereich in Größe einer Physical Erase Unit freizugeben, der dann vom Schwanz des Logs wieder benutzt werden kann. Dazu wird jede Inode ab dem Kopf des Logs untersucht. Wenn sie ungültig ist, wird der Bereich freigegeben, ansonsten wird sie am Schwanz des Logs neu geschrieben[178].
6.2.7.3.2 Wear Leveling
Wear Leveling wird von so einem Log-Structured-Dateisystem nahezu automatisch erledigt. Im Gegensatz zu anderen Dateisystemen, bei denen die Daten In-place geändert werden, schreibt JFFS einfach einen neuen Datensatz an das Ende des Logs. Dies würde bei häufigem Ändern einer bestimmten Datenbereichs bei Flashspeichern dazu führen, dass die Lebenszeit der zugrunde liegende Speicherblöcke stark reduziert wird. Durch das Fortschreiben in einer Logstruktur werden die Daten automatisch gleichmäßig auf dem Medium verteilt und somit die Lebenszeit des Flashbausteine besser genutzt. Außerdem müsste sonst vor jedem Beschreiben eines Speicherbereichs die zugehörige Physical Erase Unit gelöscht werden, welches die Performance stark beeinträchtigt[179].
6.2.8 TrueFFS
6.2.8.1 Name und Ursprung
TrueFFS (True Flash File System) ist ein Dateisystem, dass speziell für Flashspeicher entwickelt und optimiert wurde. Entwickelt wurde es von der Firma M-Systems, welche später von SanDisk übernommen wurde. Genauer handelt es sich bei TrueFFS um eine Softwareschicht (beziehungsweise Treiber), die sich zwischen Betriebssystem und dem Flashspeicher befindet. TrueFFS sorgt dafür, dass das Betriebssystem den Flashspeicher wie eine normale blockbasierte Festplatte ansprechen kann[180].
6.2.8.2 Verwendung und Einsatzgebiete
Das Haupteinsatzgebiet von TrueFFS ist sicherlich der Bereich der flashspeicherbasierten Datenträger. Weiterhin steht es insbesondere in Zusammenhang mit der Technologie Disk on Chip (DOC), welche ebenfalls von M-Systems entwickelt wurde.
6.2.8.3 Allgemeine Eigenschaften
Abbildung 10: Schematischer Aufbau der TrueFFS Partition[181]
|
TrueFFS besteht aus verschiedenen Schichten, die in der Abbildung 11 dargestellt sind. Die oberste Schicht ("Driver Layer") stellt die Schnittstelle zum Betriebssystem dar und stellt blockorientierte Zugriffsmöglichkeiten bereit. Der mittlere Teil ist das Herzstück von TrueFFS und enthält die Logik für das dynamische Mapping zwischen den logischen Blöcken und den physikalischen Sektoren des Flashspeichers. Diese Schicht deckt auch das Bad Block Handling ab und sorgt für ein entsprechendes Wear Leveling. Der unterste Block ist für die hardwarenahe Abbildung der Lese- und Schreib- beziehungsweise Löschvorgänge zuständig.
6.2.8.4 Spezielle Eigenschaften
- Wear-Leveling
Im Normalfall kann ein NAND-Flashspeicher ca. 100.000-mal wiederbeschrieben werden. Solange kein Wear-Leveling eingesetzt wird, wird jedem logischen Sektor ein physikalischer Sektor fest zugeordnet. Gemäß den Beschränkungen von Flashspeicher, muss vor dem Wiederbeschreiben eines Sektors ein Löschen der Daten erfolgen. Dies erfolgt aber nicht aber Basis der vorliegenden Sektoren, sondern auf Basis der vorliegenden Physical Erase Units. Jeder Flashspeicher ist in solche Bereiche eingeteilt. Eine Physical Erase Unit ist der kleinste Speicherbereich, der mit einer einzelnen Operation gelöscht werden kann. Diese Physical Erase Units sind wiederrum in physikalische Sektoren eingeteilt. Das heißt, wenn ein physikalischer Sektor wiederbeschrieben werden muss, dann ist es zunächst notwendig, dass die zugehörige Physical Erase Unit gelöscht wird. Ausgehend davon ist beispielsweise FAT als Dateisystem ungeeignet für Flashspeicher. Dies ist darin begründet, dass die FAT-Tabelle bei Änderungen an den Daten auf dem Datenträger immer mitgeschrieben werden muss. Dies reduziert die Lebensdauer von Flashspeichern stark[182].
Wear-Leveling sorgt nun dafür, dass sich wiederholende Schreibzyklen auf einen logischen Sektor gleichmäßig über das Speichermedium verteilt werden. Dies wird durch eine dynamische Zuordnung von logischen Sektoren zu physikalischen Sektoren gewährleistet[183].
- Error Detection Code/Error Correction Code
NAND-Flashspeicher tendiert dazu, dass ungewollte Bitfehler auftreten können (Bit Flipping). TrueFFS verwendet für die Erkennung und Behebung solcher Fehler die den BCH-Code und den Hamming-Algorithmus. Der Hamming-Algorithmus ist in der Lage einfache Bitfehler zu korrigieren und zweifache Bitfehler zu erkennen. Der große Vorteil des BCH-Algorithmus (Bose-Chaudhuri-Hocquenghem) liegt in der Erkennung von gehäuften wie auch von sehr verstreuten Bitfehlern[184] [185].
- Bad Block Handling
Konstruktionsbedingt werden gerade NAND-Flashbausteine oftmals bereits mit fehlenhaften Blöcken ausgeliefert. Aufgabe des Dateisystems ist es hier nun bei Inbetriebnahme diese fehlerhaften Blöcke zu scannen und diese dann im Fortverlauf nicht mehr zu verwenden. Auch während des Betriebs können immer wieder einzelne Blöcke verstreut auf dem Flashmedium ausfallen. Auch dies muss das Dateisystem berücksichtigen. TrueFFS nutzt dafür eine Multi-Plane-Architektur um diese Bad Blocks zu managen[186].
SanDisk hat bereits angekündigt einen Nachfolger für TrueFFS auf den Markt zu bringen: ExtremeFFS. Ähnlich wie TrueFFS ist auch ExtremeFFS dazu in der Lage ein dynamisches Mapping zwischen logischen und physikalischen Sektoren abzubilden. Um die Performance des Flashspeichers weiter zu erhöhen, wird ein Flaschenhals teilweise ausgehebelt. Problematisch sind bislang stets die Löschzyklen, die vor einem kompletten Wiederbeschreiben eines Sektors notwendig sind. ExtremeFFS unterscheidet nun verschiedene Prozesse, die auf dem Flashspeicher arbeiten können. So sorgt sich ein Prozess um die Schreibvorgänge, ein weiterer Prozess kümmert sich um die Garbage Collection und ein weiterer Prozess liefert Daten für Leseanfragen. Die Schreibvorgänge werden so vorgenommen, dass stets in einen leeren Speicherbereich geschrieben wird. Die Garbage Collection sorgt dann dafür, dass die "veralteten" Pages wieder freigegeben werden. Somit kann ein weitaus höherer Datendurchsatz bei Schreibvorgängen stattfinden, da die zugehörigen Löschzyklen verzögert ausgeführt werden. Ein weiterer Vorteil ist laut SanDisk die Eigenschaft, dass ExtremeFFS Nutzerverhalten erkennt, aufzeichnet und die Elemente entsprechend auf dem Datenträger ablegt. Hieraus sollen sich laut SanDisk weitere Performancegewinne ergeben[187].
7 Vergleich anhand von Fallbeispielen
Im Folgenden wird das Zusammenspiel der vorgestellten Speichertechnologien und Dateisystemen verglichen. Neben dem reinen technischen Vergleich, bei dem es vor allem um Performance, Sicherheit und Skalierbarkeit geht, werden auch wirtschaftliche Kriterien betrachtet. Es sollen vor allem Technologien verglichen werden, die im betrieblichen Einsatz zum Tragen kommen.
Unter Kapitel 5 - Datenträger wurde gezeigt, dass sich optische Medien wie die CD, DVD und Blu Ray vor allem im privaten Umfeld als Datenträger für Audio- und Videoinhalte durchgesetzt haben. Im Unternehmensumfeld werden diese Datenträger natürlich auch verwendet, doch ist ihre Bedeutung hier eher gering. Ähnlich verhält es sich mit der RAM-Disk die zu den flüchtigen Medien zählt und auch die Flash Speicher für den privaten Gebrauch, wie Speicherkarten und USB-Sticks, haben kaum relevante Eigenschaften, die Vorteile hinsichtlich der Datenspeicherung innerhalb eines Unternehmens bieten. Daher werden in den folgenden Anwendungsbeispielen hauptsächlich Solid-State-Disks und magnetische Datenträger betrachtet.
7.1 Zielsetzung
Ziel des folgenden Vergleichs ist es herauszufinden, ob durch den Einsatz bestimmter Speicher-Dateisystem-Konstellationen im betrieblichen Umfeld Vorteile entstehen. Es werden anhand von Fallbeispielen und Anforderungen aus realen Projekten Lösungsmöglichkeiten für den betrieblichen Einsatz aufgezeigt.
Der bei dieser Betrachtung verwendete Fokus liegt daher auf der Ermittlung einer idealen technischen Lösung die in die vorhandene Infrastruktur eingebunden werden kann, sowie der betriebswirtschaftlichen Betrachtung, die sich aus Kosten für die Anschaffung, Investition und potenziellen operativen Kosten zusammensetzen. Zu den operativen Kosten werden in diesen Fallbeispielen unter anderem Aufwendungen für Know-how-Aufbau, Wartung und Integration gezählt.
Für den Fall, dass es mehr als eine Lösung für das gestellte Szenario gibt, werden die Alternativen eines Vergleichs anhand einer Kostenvergleichsrechnung[188] [189] untersucht.
Für die Kostenvergleichsrechnung werden die folgenden Daten festgelegt:
- Die im Szenario beschriebenen Werte bezüglich Speicherplatz-, Leistungsbedarf und Wachstumsrate der Anforderungen sind stabil über den kompletten Betrachtungszeitraum
- Energiekosten: 30 Cent/KW Strom
- Gemeinkosten und Kosten die für Mitarbeiter anfallen, wie z.B. Raumkosten, Büromaterial und Gehälter, werden über eine interne Pauschale zu einem Tagessatz von 600 EUR berücksichtigt
- Die Abschreibung erfolgt linear
- Kalkulatorischer Zins: 12 Prozent
7.2 Fallbeispiel 1: Mailsystem mit Archiv
7.2.1 Anforderung/Situation
Ein großes Unternehmen möchte sein aktuell dezentrales Groupwaresystem zentralisieren. Damit verbunden ist die Auswahl eines Speichersystems welches die E-Mail- und Archivdatenbanken aufnehmen soll.
Die Dimensionierung der Lösung sollte so konzipiert sein, dass ausreichend Speicherplatz für die Aufnahme von 3500 E-Maildatenbanken je 500 MB plus den dazugehörigen Archivdatenbanken vorhanden ist. Die Organisation der Archivdatenbanken ist so gestaltet, dass es für jeden Besitzer einer E-Maildatenbank für jedes vorherige Kalenderjahr eine Archivdatenbank gibt, die auf eine maximale Größe von 1000 MB limitiert ist. Im Onlinezugriff werden immer nur die Archivdatenbanken der vorherigen zwei Kalenderjahre gehalten, alle älteren befinden sich ausschließlich auf Band. Ein Zuwachs des Speicherbedarfs für die E-Mailkommunikation muss, für die Bestimmung des aktuell und in naher Zukunft benötigten Speicherplatzes, nicht berücksichtigt werde, da die Kapazitäten der Archivdatenbanken im Durchschnitt erst zu 50% genutzt werden. Trotzdem muss die Lösung Erweiterungsmöglichkeiten bieten.
Die Systemarchitektur des neuen zentralen Groupwaresystems, welches für die E-Mailkommunikation genutzt wird, soll aus einem Failover-Cluster aus zwei Servern bestehen, die beide als Betriebssystem Windows Server 2008 in einer 64 Version verwenden. Die Infrastruktur in der sich die Systeme befinden, ist eine homogene Microsoft Windows Landschaft, die über ein zentrales Microsofts "Active Directory" verwaltet wird. Administrative Arbeiten sollen durch vorhandenes Personal durchgeführt werden. Wissen über den Aufbau und die Administration von Windows Server 2008 und der Groupwaresoftware sind im Unternehmen vorhanden. Eine Datenverschlüsselung auf Dateisystemebene wird nicht benötigt, da die Mail- und Archivdatenbanken so verschlüsselt sind, dass nur das E-Mailsystem und der Eigentümer der Datenbank diese lesen und verändern darf.
Die Nutzungsdauer der Systeme soll der gesetzlichen Abschreibungsdauer entsprechen.
7.2.2 Analyse und Lösungsmöglichkeiten
Aus der Situationsbeschreibung und den Anforderungen ist erkennbar, dass eine Speicherlösung gesucht ist die zwei verschiedene Sets an Anforderungen erfüllen muss. Das Umfeld eines klassischem E-Mailsystems besteht in der Regel aus vielen E-Mails, die meist keine lange Lebenszeit haben, woraus das Arbeiten mit kleinen Datenmengen und Dateien resultiert. Neben der Verwaltung der Informationen, kommen zusätzlich viele zeitgleiche Anfragen durch die Benutzer des Systems hinzu, die verarbeitet und unmittelbar beantwortet werden sollten. In diesem konkretem Fall hält das E-Mailsystem seine Daten mit denen es arbeitet nicht in einzelnen kleinen Dateien vor, sondern organisiert diese in einer eigenen Datenbankstruktur. Diese Eigenschaft reduziert die Anforderungen an das Dateisystem effizient mit Speicherplatz hinsichtlich kleiner Dateien umzugehen. Allerdings verlagert dies die administrative Arbeit in das E-Mailsystem.
Die durch das E-Mailsystem ebenfalls bereitgestellte Archivfunktionalität besitzt grundlegend andere Eigenschaften. Die Datenbanken des Archivsystems besitzen eine feste Größe, die sich ,wie der Inhalt auch, nach dem Anlegen nicht mehr verändert. Dies bedeutet in Bezug auf das eingesetzte Dateisystem, dass eine Datenbankdatei keiner "natürlichen" Fragmentierung durch die Nutzung unterliegen wird. Ein weiterer Unterschied liegt in der Nutzung von Archiven durch den Benutzer. Das Arbeiten in, respektive mit einem Archiv bezieht sich auf Suchanfragen in diesem Archiv. Diese Aktivitäten erzeugen auf Grund ihrer Nutzung weniger Transaktionen, als das normale Arbeiten mit aktuellen E-Mails. Darüber hinaus sind die Erwartung des Benutzers an die Antwortzeit nicht so hoch.
Auf Basis dieser Aufteilung und den Informationen der Nutzeranzahl, E-Mail- und Archivdatenbankgrößen lassen sich folgende Grundanforderungen zusammenfassen:
| E-Mailsystem | E-Mailarchivsystem | |
| Speicherbedarf (ohne BS)
(User x Datenbankgröße x Jahrgänge) | 1750 GB | 7000 GB |
| IOPS | 800 bis 1200 | 200-300 |
| Datentransferrate | mittel | gering |
| Fragmentierung | hoch | gering |
| Verfügbarkeit | hoch | mittel |
| Integrität/Stabilität | hoch | hoch |
Zusätzlich zu den Grundanforderungen kommen entsprechend Kapitel 6.1, inklusive seiner Unterkapiteln, noch weitere Anforderungen aus den Gebieten Performance und Sicherheit hinzu.
Für das E-Mailsystem gelten seitens der Anforderungen an die Performance die dort beispielsweise angegebenen Eigenschaften des E-Mailservers, mit der Ausnahmen, dass bei dem hier verwendetem System nicht massenhaft Dateien angelegt und gelöscht werden, sondern überwiegend innerhalb der Maildatenbanken der Benutzer gearbeitet wird. Trotzdem kann es vorkommen, dass die Maildatenbanken auf Grund ihrer Größe und der Anzahl der Änderungen fragmentieren. Aus diesem Grund sind kurze Zugriffszeiten bei zufälligen Zugriffen wichtig. Das Kriterium "effizient viele parallele Anfragen bearbeiten zu können" ergibt sich durch die Anzahl der Benutzer und deren Tätigkeiten in ihren Maildatenbanken.
Da es sich bei einem E-Mailsystem in der heutigen Zeit um eine geschäftskritische Anwendung handelt, muss eine hohe Verfügbarkeit des Dienstes gewährleistet werden. Neben der Notwendigkeit Ausfälle zu verhindern, ergibt sich die Notwendigkeit nach aufgetretenen Ausfällen das System schnellst möglichst wieder verfügbar zu machen und Wartungszeiträume, die sich negativ auf die Verfügbarkeit auswirken, zu minimieren. Für die in Kapitel 6.1.2 aufgezeigten Anforderungen an das Dateisystem bedeutet dies, dass es unerlässlich ist, ein Dateisystem mit Journalingfunktion zur schnellen Wiederinbetriebnahme nach einem Absturz, Snapshotunterstützung für Datensicherungen im laufendem Betrieb und wenn möglich Checksummen zur ständigen Prüfung der Datenintegrität einzusetzen. Die RAID-Funktionen sollten ebenfalls vorhanden sein, können aber wahlweise durch das Dateisystem oder einen RAID-fähigen Speicherkontroller realisiert sein.
Das E-Mailarchivsystem stellt seitens der Performance wesentlich geringere Anforderungen, was sich in der Auswahl der einsetzbaren Speichertechnologie niederschlägt. Auf Grund der benötigten Verfügbarkeit und dem notwendigem Erhalt der Datenintegrität sollte ein Dateisystem mit Journalfunktion und wenn möglich Checksummen eingesetzt werden. Die RAID-Funktionen können ebenfalls durch das Dateisystem oder den Speicherkontroller realisiert sein.
Für die Auswahl an nutzbarer Speichertechnologie ergeben sich zwei Profile. Für das E-Mailsystem wird eine performante Speichertechnologie benötigt, die vor allem kurze Zugriffszeiten besitzt. Und für das E-Mailarchivsystem ist eher das Kriterium der Größe des Speicherplatzes wichtig.
Neben diesen Grundanforderungen und Eigenschaften, die sich aus der Applikation ergeben, muss zusätzlich eine Umgebungsanforderung erfüllt werden. Als Betriebssystem für das E-Mailsystem und das E-Mailarchivsystem wird Windows Server 2008 (64-Bit) verwendet. Windows Server 2008 unterstützt für lokal angebundene Datenträger, die Windows Server 2008 selber verwaltet, nur NTFS und FAT32.1[190]
Aus den vorher gehenden Überlegungen und den in den Kapiteln 5.1, 5.3 und 6.2 lassen sich folgenden Lösungsmöglichkeiten/Konfigurationen zusammenstellen:
| Lösung | E-Mailsystem | E-Mailarchivsystem |
| 1 | Verwendung von lokalen magnetischen Festplatten. Verwaltung durch das Betriebssystem des E-Mailsystems.
| Verwendung von lokalen magnetischen Festplatten. Verwaltung durch das Betriebssystem des E-Mailarchivsystems.
|
| 2 | Verwendung von magnetischen Festplatten. Verwaltung des Speicherpools durch einen extra Server (Linux). Anbindung an den Server des E-Mailsystems über Ethernet als Netzlaufwerk.
| Verwendung von magnetischen Festplatten. Verwaltung des Speicherpools durch einen extra Server (Linux). Anbindung an den Server des E-Mailsystems über Ethernet als Netzlaufwerk.
|
| 3 | Verwendung von SSD Speicher und magnetischen Festplatten. Verwaltung des Speicherpools durch einen Solaris 10 Server. Anbindung an den Server des E-Mailsystems über Ethernet.
| - keine dritte Lösung - |
7.2.3 Entscheidungsempfehlung
Die Analyse hat gezeigt, dass es erhebliche Unterschiede zwischen dem E-Mailsystem und dem E-Mailarchivsystem seitens der Eigenschaften und Anforderungen gibt. Der Betrieb des E-Mail- und Archivdienstes auf einem gemeinsamen Speichersystem ist nicht sinnvoll, da das Speichersystem des E-Mailarchivsystem für das E-Mailsystem nicht performant und das des E-Mailsystems für das E-Mailarchivsystem zu teuer ist.
Daher gibt es nur zwei Architekturen, die auf Ihre Kosten genauer untersucht werden müssen:
- Ein gemeinsamer Failover-Cluster aus zwei Servern für die E-Mail- und Archivfunktionalität. In diesem Fall sollte kein lokales Speichersystem verwendet werden, sondern die Lösungen "E-Mailsystem"x"Lösung 2" oder "E-Mailsystem"x"Lösung 2" und "E-Mailarchivsystem"x"Lösung 2" aus der Tabelle mit den Lösungsmöglichkeiten aus Kapitel 7.2.2. Die Speichersysteme müssen nicht pro Clusterpartner vorhanden sein und könnten gemeinsam genutzt werden, falls der Speicherplatz dieser Systeme verdoppelt wird und jeder Clusterpartner seinen eigenen Speicherbereich zugeteilt bekommt. Dies würde die Kosten leicht reduzieren, allerdings einen "single of point failure" im Failover-Cluster-Konzept schaffen. Aufgrund der Anforderung, dass das E-mailarchivsystem eine mittlere Verfügbarkeit gewährleisten muss, wird diese Option im Kostenvergleich angeführt.
- Zwei Failover-Cluster mit je zwei Servern. Ein Serverpaar für das E-Mailsystem und ein weiteres für das E-Mailarchivsystem. Es werden lokale Speichersysteme, aufgezeigt in der Tabelle mit den Lösungsmöglichkeiten aus Kapitel 7.2.2 unter "Lösung 1". Jeder Server muss dabei über ein eigenes dediziertes Speichersystem verfügen.
Kostenvergleichsrechnung
Als Anschaffungskosten der für die Lösungen benötigten Serverhardware (ohne Speichersysteme) werden folgende Kosten zugrunde gelegt:
| Serversystem | Kosten |
| Server E-Mailsystem externes Speichersystem
(2HE,2xIntel X5560,12GiB DDR3 RAM, 2x74GB 15k SAS, MS Windows Server2008 64-bit) | 5400,00 € |
| Server E-Mailsystem lokales Speichersystem
(4HE,2xIntel E5460,16GiB DDR3 RAM, SAS-RAID 28 Ports, MS Windows Server2008 64-bit) | 7050,00 € |
| Server E-Mailarchivsystem externes Speichersystem
(2HE,2xIntel E5506,6GiB DDR3 RAM, 2x74GB 15k SAS, MS Windows Server2008 64-bit) | 3000,00 € |
| Server E-Mailarchivsystem lokales Speichersystem
(4HE,2xIntel E5205,8GiB DDR3 RAM, SATA-RAID 28 Ports, MS Windows Server2008 64-bit) | 4300,00 € |
| Server Speichersystem SAS
(4HE,1xIntel E5205,4GiB DDR2 RAM,SAS-RAID 28 Ports, Linux) | 3700,00 € |
| Server Speichersystem SATA
(4HE,1xIntel E5205,4GiB DDR2 RAM,SATA-RAID 28 Ports, Solaris 10) | 3500,00 € |
| Server Speichersystem SATA (mit SSD als Cache)
(4HE,1xIntel E5205,4GiB DDR2 RAM,SATA-RAID 28 Ports, Solaris 10) | 3500,00 € |
Für die Installation und das Einrichten wird pro Server (ggf. Mit Speichersystem) mit 8 Stunden internem Aufwand gerechnet, was genau einem Full Time Equivalent (FTE) entspricht. Für den Energiebedarf eines Servers wird ein einheitlicher und durchschnittlicher Wert von 300 Watt ohne Speichersystem verwendet.
| Anlage | Architektur 1: externer Speicher Variante 1 | |||
| Anschaffungskosten | ||||
| Clusterserver 1 | ||||
| Hardware + Betriebssystem | 5.400,00 € | |||
| Clusterserver 2 | ||||
| Hardware + Betriebssystem | 5.400,00 € | |||
| Speicherserver E-Mailfunktionalität f. Clusterserver 1 | ||||
| Hardware + Betriebssystem | 3.700,00 € | |||
| Festplatten (16x SAS HDD) | 6.400,00 € | |||
| Speicherserver E-Mailfunktionalität f. Clusterserver 2 | ||||
| Hardware + Betriebssystem | 3.700,00 € | |||
| Festplatten (16x SAS HDD) | 6.400,00 € | |||
| Speicherserver Archivfunktionalität f. Clusterserver 1 u. 2 | ||||
| Hardware + Betriebssystem | 3.700,00 € | |||
| Festplatten (16x S-ATA HDD) | 4.200,00 € | |||
| => | 38.900,00 € | |||
| Anschaffungsnebenkosten | ||||
| Installation | 3.000,00 € | |||
| Training/Schulung der Mitarbeiter (400 € / Tag) | 800,00 € | |||
| => | 3.800,00 € | |||
| Nutzungsdauer | 5 Jahre, danach Restbuchwert: 0 € | |||
| Durchschnittlich gebundenes Kapital | 21.350,00 € | |||
| Kosten pro Jahr | ||||
| Abschreibung | 8.540,00 € | |||
| Kapitalkosten | 12% pro Jahr | 2.562,00 € | ||
| Energiekosten Server | pro Jahr | 3.942,00 € | ||
| Energiekosten Speichersysteme | pro Jahr | 2.323,15 € | ||
| Kosten pro Jahr | 17.367,15 € | |||
| Anlage | Architektur 1: externer Speicher Variante 2 | |||
| Anschaffungskosten | ||||
| Clusterserver 1 | ||||
| Hardware + Betriebssystem | 5.400,00 € | |||
| Clusterserver 2 | ||||
| Hardware + Betriebssystem | 5.400,00 € | |||
| Speicherserver E-Mailfunktionalität f. Clusterserver 1 (m. SSD) | ||||
| Hardware + Betriebssystem | 3.500,00 € | |||
| SSD 64 GB für Cache | 770,00 € | |||
| Festplatten (14x S-ATA HDD) | 980,00 € | |||
| Speicherserver E-Mailfunktionalität f. Clusterserver 2 (m. SSD) | ||||
| Hardware + Betriebssystem | 3.500,00 € | |||
| SSD 64 GB für Cache | 770,00 € | |||
| Festplatten (14x S-ATA HDD) | 980,00 € | |||
| Speicherserver Archivfunktionalität f. Clusterserver 1 u. 2(m. SSD) | ||||
| Hardware + Betriebssystem | 3.700,00 € | |||
| Festplatten (28x S-ATA HDD) | 4.200,00 € | |||
| => | 29.200,00 € | |||
| Anschaffungsnebenkosten | ||||
| Installation | 3.000,00 € | |||
| Training/Schulung der Mitarbeiter (400 € / Tag) | 800,00 € | |||
| => | 3.800,00 € | |||
| Nutzungsdauer | 5 Jahre, danach Restbuchwert: 0 € | |||
| Durchschnittlich gebundenes Kapital | 16.500,00 € | |||
| Kosten pro Jahr | ||||
| Abschreibung | 6.600,00 € | |||
| Kapitalkosten | 12% pro Jahr | 1.980,00 € | ||
| Energiekosten Server | pro Jahr | 3.942,00 € | ||
| Energiekosten Speichersysteme | pro Jahr | 1.634,62 € | ||
| Kosten pro Jahr | 14.156,62 € | |||
| Anlage | Architektur 2: lokaler Speicher | |||
| Anschaffungskosten | ||||
| Clusterserver 1: E-Mail System | ||||
| Hardware + Betriebssystem | 7.060,00 € | |||
| Festplatten (16x SAS HDD) | 6.400,00 € | |||
| Clusterserver 2: E-Mail System | ||||
| Hardware + Betriebssystem | 7.060,00 € | |||
| Festplatten (16x SAS HDD) | 6.400,00 € | |||
| Clusterserver 1: E-Mail Archivsystem | ||||
| Hardware + Betriebssystem | 4.300,00 € | |||
| Festplatten (14x S-ATA HDD) | 980,00 € | |||
| Clusterserver 2: E-Mail Archivsystem | ||||
| Hardware + Betriebssystem | 4.300,00 € | |||
| Festplatten (14x S-ATA HDD) | 980,00 € | |||
| => | 37.460,00 € | |||
| Anschaffungsnebenkosten | ||||
| Installation | 3.600,00 € | |||
| Training/Schulung der Mitarbeiter (400 € / Tag) | 0,00 € | |||
| => | 3.600,00 € | |||
| Nutzungsdauer | 5 Jahre, danach Restbuchwert: 0 € | |||
| Durchschnittlich gebundenes Kapital | 20.530,00 € | |||
| Kosten pro Jahr | ||||
| Abschreibung | 8.212,00 € | |||
| Kapitalkosten | 12% pro Jahr | 2.463,60 € | ||
| Energiekosten Server | pro Jahr | 3.153,60 € | ||
| Energiekosten Speichersysteme | pro Jahr | 2.323,15 € | ||
| Kosten pro Jahr | 16.152,35 € | |||
Würde man die Entscheidung ausschließlich von der Kostenvergleichsrechnung abhängig machen, dann würde die Entscheidung auf die Umsetzung der "Architektur 1: externer Speicher Variante 2" fallen. Die zugrunde liegende Technik und Kombination nutzt die Vorteile der geringen Zugriffszeiten der SSD-Technik und kombiniert diese mit dem niedrigen Preis pro GB der SATA-Speichertechnologie. Darüber hinaus verbraucht diese Hybrid-Technologie weniger Strom, als Lösungen die ausschließlich auf SAS oder SATA-Speicher setzen. Die Nachteile ergeben sich daraus, dass ein weiterer Server benötigt wird und dass speziell in diesem Szenario noch Wissen in Bezug auf die Technologie und die Plattform aufgebaut werden muss.
Hier hat die "Architektur 2" entscheidende Vorteile, da diese sich ideal in die bestehende Infrastruktur einfügt und die Kosten nicht wesentlich höher sind als die der "Architektur 1 Variante 2". Zusätzlich, obwohl dies nicht unbedingt gefordert ist, ist auch das komplette Speichersystem des E-Mailarchivservers doppelt ausgelegt und erhöht damit die Ausfallsicherheit beziehungsweise reduziert das Risiko einer Nichtverfügbarkeit des Dienstes.
7.3 Fallbeispiel 2: Speichersubsystem für einen Datenbankserver
7.3.1 Anforderung/Situation
Szenario: Ein mittelständisches Unternehmen plant die Ablösung vieler kleinerer Datenbankserver durch ein ausfallsicheres Clustersystem. Das Clustersystem benötigt keinen gemeinsam genutzten Speicher, sondern verwendet Replikationstechnologien um die Daten für alle Clusterknoten verfügbar zu machen.
Das aktuelle Datenvolumen beläuft sich auf ca. 1,5TB. Durch Lastmessungen auf den Altsystemen wurde eine durchschnittliche Gesamtlast von 3000 IOPS auf den bisher genutzten Speichersystemen ermittelt. Die beobachteten Spitzenwerte liegen bei 3500 IOPS. Der verwendete Speicher soll ausfallsicher konfiguriert werden können.
Es wird mit einer Steigerung der Ressourcennutzung von ca. 20% innerhalb der nächsten 2 Jahre gerechnet. Das Unternehmen setzt derzeit ausschließlich lokale Speichertechnologien ein. Sollte der Aufbau eines Speichernetzes erforderlich sein, so muss die Schulung der Mitarbeiter auf das neue System berücksichtigt werden.
Zu den technischen Kriterien die verglichen werden zählen Random Lese- und Schreibzugriffe, sowie Sequentielle Lese- und Schreibzugriffe. Die wirtschaftlichen Kriterien stellen den Bezug zwischen Performance und Preis her.
Die auf dem Datenbankserver bereitgestellten Datenbanken sind als geschäftskritisch einzustufen. Dies muss bei der Auswahl der Technologie berücksichtigt werden.
7.3.2 Analyse und Lösungsmöglichkeiten
Das Fallbeispiel beinhaltet zwei technische Anforderungen die näher untersucht werden müssen. Das aktuelle Datenvolumen ist mit 1,5TB relativ gering. Es ist zu erwarten, dass sich die benötigten IOPS nur mit einer hohen Anzahl an Speichermedien erreichen lässt. Auch das voraussichtliche Wachstum von 20% innerhalb der nächsten 2 Jahre ist aus technischer Sicht zu vernachlässigen. Anders verhält es sich mit den IOPS. Folgende Rechnung zeigt, dass bei der Nutzung von herkömmlichen Disksubsystemen eine Vielzahl an Festplatten benötigt wird, um Spitzenwerte von 3500 IOPS zu erreichen: 3500 IOPS (gefordert) / 150 IOPS (Standard SAS Festplatte) = 23,3 Festplatten Das bedeutet für eine gespiegelte Lösung benötigen wir 48 SAS Festplatten. Bei SAS Festplatten mit 15.000 rpm ist von durchschnittlich 150 IOPS pro Festplatte auszugehen. Bei der Verwendung der heutzutage üblichen 146GB SAS Festplatte, wird eine Nettokapazität von ca. 3,4TB erreicht und somit weit über den Anforderungen liegt.
Mit der Kenntnis des ermittelten Engpasses werden zwei Lösungsansätze verfolgt. Der erste Ansatz beschreibt eine reine SAS basierte Lösung und der zweite Ansatz eine hybride Technologie die S-ATA mit SSD kombiniert. Hybride Technologie bedeutet, dass sowohl schnelle Solid-State-Disk Technologie, als auch etwas langsamere magnetische Datenträger eingesetzt werden. Denkbar wäre z.B. die Auslagerung des Caches auf Solid-State-Disk und die eigentliche Speicherung der Daten auf günstige S-ATA Technologie. Die Abbildung 11 zeigt den Aufbau eines solchen Systems, sowie die Schreib- und Lesevorgänge die zunächst über die Solid-State-Disk Schicht erfolgen[191].
Abbildung 11: Zwei-Tier Architektur mit SSDs und magnetischen Festplatten[192]
|
Eine rein auf SSD Technologie basierte Lösung wird hier nicht betrachtet. Für geschäftskritische Anwendungen ist es aufgrund der beschriebenen Eigenschaften von SSD (siehe Solid State Drive) nicht ratsam SSDs mit MLC Technologie einzusetzen.
Die hybride Lösung muss von dem Storagesystem und dem darauf laufenden Dateisystem unterstützt werden. Hier bieten sich z.B. wie unter 6.2.1.5 beschrieben das Dateisystem ZFS an. Das ZFS Dateisystem wird nur innerhalb des Speichersystems verwendet.
Nachfolgend werden die Kosten einer SAS basierenden Lösung mit zwei externen Festplatten Arrays und 48x 146GB SAS Festplatten zu je 350,- Euro gegen eine hybride Lösung basierend auf S-ATA Technologie für den Datenspeicher und Solid-State-Technologie für das Caching, verglichen. Für eine hybride Lösung, werden für die unter Kapitel 7.3.1 benannten Anforderungen ca. 16x 500GB S-ATA Festplatten zu je 70,- Euro und 4 auf SLC Technologie basierte Solid-State-Disks zu je 770,- Euro benötigt. Es werden marktübliche Disksubsysteme namhafter Hersteller eingesetzt. Die externen SAS Controller mit einer Kapazität von je 25 Festplatten werden mit 2.500 Euro pro Gerät angegeben. Die hybride Lösung mit 16.000 Euro.
Es wird ein durchschnittlicher Stromverbrauch von 18W für eine SAS Festplatte und 11W für eine S-ATA Festplatte angenommen. Eine Solid-State-Disk wird mit 8W angesetzt. Die Energieverbrauch der externen Systeme beläuft sich auf 600W.
Die Nutzungszeitraum der Systeme ist equivalent der gesetzlichen Abschreibungsdauer von 5 Jahren.
| Anlage | Variante 1: externer SAS Speicher | |||
| Anschaffungskosten | ||||
| Externes SAS Array | ||||
| Array inkl. Erweiterung für 50 HDDs | 5.000,00 € | |||
| Festplatten (48x SAS HDD) | 16.800,00 € | |||
| => | 21.800,00 € | |||
| Anschaffungsnebenkosten | ||||
| Installation | 600,00 € | |||
| Training/Schulung der Mitarbeiter (400 € / Tag) | 0,00 € | |||
| => | 600,00 € | |||
| Nutzungsdauer | 5 Jahre, danach Restbuchwert: 0 € | |||
| Durchschnittlich gebundenes Kapital | 11.200,00 € | |||
| Kosten pro Jahr | ||||
| Abschreibung | 2.800,00 € | |||
| Kapitalkosten | 12% pro Jahr | 1.344,00 € | ||
| Energiekosten Server | pro Jahr | 3.847,39 € | ||
| Kosten pro Jahr | 7.991,39 € | |||
| Anlage | Variante 2: Hybrid Storage Technologie (S-ATA/SSD) | |||
| Anschaffungskosten | ||||
| Externes SAS Array | ||||
| Disksubsystem (iSCSI / FC) | 16.000,00 € | |||
| Festplatten (16x S-ATA / 4x SSD HDD) | 4.20,00 € | |||
| => | 20.200,00 € | |||
| Anschaffungsnebenkosten | ||||
| Installation | 1.800,00 € | |||
| Training/Schulung der Mitarbeiter (400 € / Tag) | 800,00 € | |||
| => | 2.600,00 € | |||
| Nutzungsdauer | 5 Jahre, danach Restbuchwert: 0 € | |||
| Durchschnittlich gebundenes Kapital | 11.400,00 € | |||
| Kosten pro Jahr | ||||
| Abschreibung | 2.850,00 € | |||
| Kapitalkosten | 12% pro Jahr | 1.368,00 € | ||
| Energiekosten Server | pro Jahr | 2.070,86 € | ||
| Kosten pro Jahr | 6.288,86 € | |||
7.3.3 Entscheidungsempfehlung
Die Anforderungen werden sowohl von der Lösungsvariante 1, als auch von der Lösungsvariante 2 erfüllt. Aus diesem Grund wird nach den rein wirtschaftlichen Kriterien die Variante 2 bevorzugt.
7.4 Fallbeispiel 3: Speichersubsystem für einen Dateiserver
7.4.1 Anforderung/Situation
Szenario: Ein Unternehmen mit ca. 5000 Mitarbeitern plant die Anschaffung eines neuen Dateiservers. Das derzeitige Datenvolumen beläuft sich auf ca. 15TB und wird weiter stark zunehmen. Es soll ein System angeschafft werden, das künftig auch von anderen Servern genutzt werden kann. Denkbar wären unter anderem Emailserver, Datenbankserver und eine Kollaborationsplattform.
Der Zugriff auf das Speichersystem muss schnell und ausfallsicher sein. Für das Unternehmen kommt nur ein iSCSI oder FibreChannel SAN infrage. Es soll eine kosteneffiziente Lösung gefunden werden, wobei der Fokus nicht auf iSCSI oder FibreChannel gelegt werden soll, sondern vielmehr auf die Speichertechnologie in Form von Datenträgern und Dateisystem.
7.4.2 Analyse und Lösungsmöglichkeiten
Das relativ hohe Datenvolumen und die Anforderung weitere Systeme an das Speichersystem anzubinden, sowie die Annahme dass sich das Datenvolumen stark vergrößern wird, erfordert eine Technologie die es ermöglicht das Speichersystem sukzessive auszubauen. Das eingesetzte Dateisystem sollte nach Möglichkeit dynamisch erweiterbar sein und Funktionen für Zugriffsbeschränkungen und Betriebssicherheit wie unter 6.1.2 beschrieben, beinhalten.
Wie im vorherigen Beispiel wird auch hier ein System basierend auf SAS und ein System basierend auf S-ATA kombiniert mit Solid-State-Disk Technologie verglichen. Die SAS Technologie ist hinsichtlich sequentieller und auch zufälliger Zugriffe, wesentlich schneller als die S-ATA Technologie, dies wird wie im vorherigen Beispiel über schnellen Solid-State-Disk Speicher für das Caching kompensiert. Beide Systeme sind dynamisch erweiterbar. Das hybride System lässt es zu je nach Anforderung entweder eine Erweiterung der Speicherkapazität durch das Hinzufügen weiterer S-ATA Platten, oder eine Erweiterung der Performance hinsichtlich Zugriffsgeschwindigkeiten durchzuführen.
Für ein Speichersystem, das für verschiedene Systeme zur Verfügung stehen soll ist eine Eingrenzung auf iSCSI und FibreChannel SAN wie sie in den Anforderungen getroffen wurde, sinnvoll. Eine Vielzahl von Applikationen können bspw. nicht mit NAS Systemen, die über das CIFS, NFS oder auch HTTP Protokoll Ihren Speicher zur Verfügung stellen, umgehen.
Kapazitäten für weitere Systeme die an diese Speicherlösung angebunden werden sollen, werden nicht berücksichtigt. Es wird angenommen das die Performance eines RAID6 sowohl bei Verwendung der SAS als auch bei der Verwendung der S-ATA/SSD Technologie für den Dateiserver ausreichend ist.
Nachfolgend werden die Kosten einer SAS basierenden Lösung mit zwei externen Festplatten Arrays und 60x 300GB SAS Festplatten zu je 400,- Euro gegen eine hybride Lösung basierend auf S-ATA Technologie für den Datenspeicher und Solid-State-Technologie für das Caching, verglichen. Für die SAS Für die hybride Lösung benötigen für die unter Kapitel 7.4.1 benannten Anforderungen ca. 36x 500GB S-ATA Festplatten zu je 70,- Euro und 4 auf SLC Technologie basierte Solid-State-Disks zu je 770,- Euro. Es werden Marktübliche Disksubsysteme namhafter Hersteller eingesetzt. Die Externen SAS Controller mit einer Kapazität von je 25 Festplatten werden mit 2.500 Euro pro Gerät angegeben. Die hybride Lösung mit 16.000 Euro.
| Anlage | Variante 1: Externer SAS Speicher | |||
| Anschaffungskosten | ||||
| Externes SAS Array | ||||
| Array inkl. Erweiterung für 75 HDDs | 7.500,00 € | |||
| Festplatten (60x SAS HDD) | 16.800,00 € | |||
| => | 24.300,00 € | |||
| Anschaffungsnebenkosten | ||||
| Installation | 600,00 € | |||
| Training/Schulung der Mitarbeiter (400 € / Tag) | 0,00 € | |||
| => | 600,00 € | |||
| Nutzungsdauer | 5 Jahre, danach Restbuchwert: 0 € | |||
| Durchschnittlich gebundenes Kapital | 12.450,00 € | |||
| Kosten pro Jahr | ||||
| Abschreibung | 3.112,50 € | |||
| Kapitalkosten | 12% pro Jahr | 1.494,00 € | ||
| Energiekosten Server | pro Jahr | 5.203,44 € | ||
| Kosten pro Jahr | 9.809,94 € | |||
| Anlage | Variante 2: Hybrid Storage Technologie (S-ATA/SSD) | |||
| Anschaffungskosten | ||||
| Externes SAS Array | ||||
| Disksubsystem (iSCSI / FC) | 16.000,00 € | |||
| Festplatten (36x S-ATA / 4x SSD HDD) | 5.600,00 € | |||
| => | 21.600,00 € | |||
| Anschaffungsnebenkosten | ||||
| Installation | 1.800,00 € | |||
| Training/Schulung der Mitarbeiter (400 € / Tag) | 800,00 € | |||
| => | 2.600,00 € | |||
| Nutzungsdauer | 5 Jahre, danach Restbuchwert: 0 € | |||
| Durchschnittlich gebundenes Kapital | 12.100,00 € | |||
| Kosten pro Jahr | ||||
| Abschreibung | 3.025,00 € | |||
| Kapitalkosten | 12% pro Jahr | 1.452,00 € | ||
| Energiekosten Server | pro Jahr | 2.070,86 € | ||
| Kosten pro Jahr | 6.547,86 € | |||
7.4.3 Entscheidungsempfehlung
Die Anforderungen werden sowohl von der Lösungsvariante 1, als auch von der Lösungsvariante 2 erfüllt. Aus diesem Grund wird nach den rein wirtschaftlichen Kriterien die Variante 2 bevorzugt.
7.5 Interpretation
Eine generelle Aussage über den Einsatz der einen oder anderen Technologie ist nicht möglich. Es müssen bei der Auswahl der Speichertechnologie und des Dateisystems verschiedene Faktoren berücksichtigt werden. Einen besonders hohen Stellenwert haben bei einem Auswahlverfahren die vorhandene Infrastruktur, die gewünschte Integrationstiefe wie bspw. die Einbindung an zentrale Verzeichnisdienste, sowie das vorhandene betriebliche Wissen. Wie bereits im ersten Fallbeispiel deutlich wurde, kann es unter Umständen sinnvoller sein zwei lokale Speichersystem einem zentralen Speichernetz vorzuziehen. Es ist nur selten sinnvoll sich rein auf die technischen Gesichtspunkte bei der Bewertung von Dateisystemen und Speicherlösungen zu konzentrieren und dabei den Blick für andere Einflussfaktokren zu verlieren. Wie unter Kapitel 5.1.2 und Kapitel 5.1.4 werden P-ATA und SCSI nur noch selten eingesetzt. Neue Technologien wie Solid-State-Disk haben sich aufgrund ihres Preises und der bisher fehlenden praktischen Erfahrungswerte, im betrieblichen Umfeld noch nicht durchsetzen können.
8 Fazit und Ausblick
Es wurden innerhalb dieser Arbeit viele Technologien vorgestellt, angefangen bei Protokollen über Datenträger hin zu Dateisystemen. Im letzten Kapitel wurden Anwendungsfälle aus der Praxis dargestellt und verschiedene Lösungsmöglichkeiten hierfür aufgezeigt.
Während der Einsatz von Solid-State-Disks auf Arbeitsplatzrechner und mobilen Geräten, wie PDAs und Notebooks, mittlerweile sehr interessant geworden ist, so ist diese Technologie trotz der rasant fallenden Preise bisher eher selten im Rechenzentrum vertreten. Doch gerade hier ist ein erheblicher Mehrwert durch den geringen Stromverbrauch zu erwarten. Die Solid-State-Disks ist eine sehr interessante Technologie und wird sich vermutlich langfristig durchsetzen können. Mittelfristig ist zu erwarten, dass die in den Fallbeispielen und unter Kapitel 6.1.2.5 vorgestellten hybriden Technologien sich größerer Beliebt- und Bekanntheit erfreuen. Durch letzteres lässt sich eine Skalierung leicht nach Performance und Kapazität aufteilen. In den Fallbeispielen wurden S-ATA Festplatten für die Datenspeicherung in diesen Systemen verwendet, das muss natürlich nicht sein. Es lassen sich ebenso gut Solid-State-Technologie und SAS miteinander kombinieren.
Bei den optischen Medien ist Blu Ray aufgrund der hohen Speicherdichte für Audio- und Videoinhalte ein ebenso interessanter Kandidat wie die SSD für die elektrischen Medien. Aus dem Bereich der optischen Medien wurde mit der HVD eine weitere Technologie vorgestellt die ein enormes Potential haben könnte und sich vermutlich als Nachfolger der Blu Ray Disk etablieren wird.
Es wurde gezeigt das einige Dateisysteme wie bspw. JFFS oder TrueFFS für spezielle Speichermedien entwickelt wurden und andere Dateisysteme wie ZFS erkennen die Art des vorliegenden Mediums und passen Ihre Funktionweise hierauf an. Es wurden drei Anwendungsfälle für den Einsatz von Speichertechnologien und Dateisystemen untersucht. Anhand dieser Beispiele wurde gezeigt, dass derzeit auf dem Speichermarkt zwei Technologien dominieren. Aktuell sind im betrieblichen Umfeld vor allem Speichersysteme mit SAS Festplatten, sowie Systeme mit S-ATA Festplatten zu finden.
Eine Möglichkeit Performance und Datenvolumen zu einem attraktiven Preis zusammen zu bringen, sind die vorgestellten hybriden Speichersysteme. Allerdings sind auch diese Systeme nicht unbegrenzt skalierbar. Das Problem bei der Verwendung von Caches ist, das nicht alle Anforderungen hieraus bedient werden können, da dem Controller die Logik der darauf zugreifenden Applikation fehlt. Als Faustregel gilt aber, dass bei gemischten Leseprofilen ungefähr 40% der angeforderten Blöcke aus dem Cache bedient werden können[193]. Wird diese Technologie zusammen mit bestimmten Dateisystemen wie bspw. ZFS eingesetzt, lassen sich hierüber weitaus höhere Quoten für die Lese- und Schreibzugriffe durch Nutzung des auf SSD basierenden Caches erreichen.
Wie an hybriden Speichersystemen zu erkennen ist, hat sich das Anforderungsprofil an Dateisysteme verändert. Wurde ein Dateisystem früher für einen Einsatzbereich und eine Speichertechnologie entwickelt, wie bspw. UDF für optische Medien, werden moderne und künftige Dateisysteme unterschiedliche Speichertechnologie direkt und in Kombination miteinander unterstützen. Resultierend daraus werden Funktionen die bisher von Speicherkontrollern erbracht werden in das Dateisystem verlagert, wie dies an ZFS und BtrFS zu sehen ist.
9 Fußnoten
- ↑ Vgl. Hansen und Neumann, 2006; S. 109
- ↑ Vgl. Tanenbaum, 2006; S. 103
- ↑ Vgl. Zhang et al., 2006; S. 1f
- ↑ Vgl. Hansen und Neumann, 2006; S. 123f
- ↑ Vgl. o.V., 2009a; S. 1
- ↑ Vgl. Hansen und Neumann, 2006; S. 113
- ↑ Quelle: Masievizc, 2004; S. 18
- ↑ Vgl. Tanenbaum, 2006; S. 103f
- ↑ Vgl. Tanenbaum, 2006; S. 204f
- ↑ Quelle: Masievizc, 2004; S. 18
- ↑ Vgl. Masiewizc, 2004; S. 17
- ↑ Vgl. Masiewizc, 2004; S. 17
- ↑ Vgl. o.V., 2009a; S. 1
- ↑ Vgl. Tanenbaum, 2006; S. 105f
- ↑ Vgl. o.V., 2004a; S. 2
- ↑ Vgl. Cox, 2009; S. 23
- ↑ Vgl. Cox, 2009; S. 39
- ↑ Vgl. Cox, 2009; S. 81
- ↑ Vgl. Hansen und Neumann, 2005; S. 50f
- ↑ Vgl. Coufal und Burr, 2002; S. 2
- ↑ Vgl. Mansuripur, 1998; S. 2
- ↑ Vgl. Coufal und Burr, 2002; S. 2
- ↑ Vgl. Pohlmann, 1992; S. 11
- ↑ Vgl. Ogawa und Nakajima, 1992; S. 14f
- ↑ Vgl. Coufal und Burr, 2002; S. 3
- ↑ Vgl. Immink, 1997; S. 4
- ↑ Quelle: Immick, 1997; S. 4
- ↑ Vgl. o.V., 2004b; S. 6ff
- ↑ Vgl. o.V., 2004b; S. 27
- ↑ Vgl. o.V., 2009b; o.S.
- ↑ Vgl. o.V., 2009c; o.S.
- ↑ Vgl. Shimada et. al., 2006; S. 1
- ↑ Vgl. o.V., 2006; S. 3, 7
- ↑ Vgl. o.V., 2007a; S. 3, 7
- ↑ Vgl. o.V., 2007b; S. 3, 7
- ↑ Quelle: o.V., 2009d; o.S.
- ↑ Vgl. o.V., 2009d; o.S.
- ↑ Vgl. Shimada, et. al., 2009; S. 5-7
- ↑ Vgl. Shimada, et. al., 2009; S. 5-7
- ↑ Quelle: o.V., 2009d; o.S.
- ↑ Vgl. o.V., 2009d; o.S.
- ↑ Vgl. o.V., 2009b; o.S.
- ↑ Vgl. o.V., 2009b; o.S.
- ↑ Vgl. o.V., 2009b; o.S.
- ↑ Vgl. o.V., 2007a; o.S.
- ↑ Vgl. o.V., 2007b; o.S.
- ↑ Vgl. Shimada, et. al., 2009; S. 1
- ↑ Vgl. o.V., 2009b; o.S.
- ↑ Vgl. o.V., 2009b; o.S.
- ↑ Vgl. o.V., 2009b; o.S.
- ↑ Vgl. o.V., 2007a; S. 121
- ↑ Vgl. o.V., 2009b; o.S.
- ↑ Vgl. o.V., 2009b; o.S.
- ↑ Vgl. o.V., 2009b; o.S.
- ↑ Vgl. Karels, et.al., 1990; S. 1
- ↑ Vgl. Chiang, et. al., 1998; S. 1
- ↑ Vgl. Hutsell, et. al., 2008; S. 5
- ↑ Vgl. Callaby, et. al., 1994; S. 4
- ↑ Vgl. Woodhouse, 2001; S. 1f
- ↑ Vgl. Woodhouse, 2001; S. 1f
- ↑ Vgl. Gal und Toledo, 2005; S. 1
- ↑ Vgl. Hutsell, et. al., 2008; S. 4
- ↑ Vgl. Chang, 2008; S. 428
- ↑ Quelle: Chang, 2008; S. 429
- ↑ Vgl. Gal und Toledo, 2005; S. 3
- ↑ Vgl. Chang, 2008; S. 429
- ↑ Vgl. Hauksson und Ásmundsson, 2007; S. 4
- ↑ Vgl. o.V., 2009e; o.S.
- ↑ Vgl. Kaiser, 2007; S. 522ff
- ↑ Vgl. o.V., 2008a; Titelblatt
- ↑ Vgl. o.V., 2007a; Titelblatt
- ↑ Vgl. o.V., 2009f; o.S.
- ↑ Vgl. Weißenborn, 2008; o.S.
- ↑ Vgl. Troppens, et. al., 2008; S. 140
- ↑ Vgl. Troppens, et. al., 2008; S. 141
- ↑ Vgl. Troppens, et. al., 2008; S.142
- ↑ Vgl. Goriop, 2009; S. 10
- ↑ Vgl. Katcher, 1997; o.S.
- ↑ Vgl. Cocker, 1999; o.S.
- ↑ Vgl. Norcott, 2009; S. 1
- ↑ Vgl. Hutnagl, 2008; S. 3
- ↑ Vgl. Chinner und Higdon, 2006; S. 1f
- ↑ Vgl. o.V., 2009g; o.S.
- ↑ Vgl. o.V., 2009h; o.S.
- ↑ Vgl. o.V., 2009i, o.S.
- ↑ Vgl. Jones, 2008; S. 1f
- ↑ Vgl. Garimella, 2006; o.S.
- ↑ Vgl. Werner und Schneider, 2000; S. 510
- ↑ Vgl. o.V., 2009j; S. 59
- ↑ Vgl. o.V., 2009k; o.S.
- ↑ Vgl. o.V., 2009j; S. 275
- ↑ Vgl. o.V. 2000; S. 63
- ↑ Vgl. o.V., 2004c; o.S.
- ↑ Vgl. o.V., 2009l; o.S.
- ↑ Vgl. o.V. 2003a; S. 558
- ↑ Vgl. o.V., 2009m; o.S.
- ↑ Vgl. Johnson, 2006; S. 1
- ↑ Vgl. o.V., 2008b; o.S.
- ↑ Vgl. o.V., 2008c; o.S.
- ↑ Vgl. Solter et al., 2009; S. 223
- ↑ Vgl. o.V., 2009j; S. 34
- ↑ Vgl. Solter et al., 2009; S. 223f
- ↑ Vgl. o.V., 2008d; S. 32
- ↑ Vgl. o.V., 2009j; S. 107
- ↑ Vgl. Solter et al., 2009; S. 223
- ↑ Vgl. Solter et al., 2009; S. 224
- ↑ Vgl. o.V., 2009j; S. 25ff
- ↑ Vgl. o.V., 2009j; S. 35
- ↑ Vgl. o.V., 2009j; S. 36
- ↑ Vgl. o.V., 2009j; S. 37
- ↑ Vgl. Bitar, 2008; S. 6
- ↑ Vgl. o.V., 2008d; S. 2
- ↑ Quelle: o.V., 2008d; S. 2
- ↑ Vgl. o.V., 2009j; S. 60f
- ↑ Vgl. o.V., 2009j; S. 60
- ↑ Vgl. Sweeney et. al., 1996; o.S.
- ↑ Vgl. o.V., 2006; S. 1
- ↑ Vgl. o.V., 2009n, o.S.
- ↑ Vgl. o.V., 2009o; o.S
- ↑ Vgl. o.V., 2006; S. 1-2
- ↑ Vgl. Sweeney et. al, 1996; o.S.
- ↑ Vgl. o.V., 2006; o.S.
- ↑ Vgl. Sweeney et. al., 1996; o.S.
- ↑ Vgl. Sweeney, et. al., 1996; o.S.
- ↑ Vgl. Chinner und Higdon, 2006; S. 14
- ↑ Vgl. Chinner und Higdon, 2006; S. 10
- ↑ Vgl. Sweeney et. al., 1996; o.S.
- ↑ Vgl. Chinner und Higdon, 2006; S. 8
- ↑ Vgl. Chinner und Higdon, 2006; S. 13
- ↑ Vgl. o.V., 2009p; o.S.
- ↑ Vgl. o.V., 2007c; o.S
- ↑ Vgl. o.V., 2009q; o.S.
- ↑ Vgl. Pachuchiy, 2007; S. 24f
- ↑ Vgl. Brünning und Krause, 2006; S. 144
- ↑ Vgl. Brünning und Krause, 2006; S. 149
- ↑ Vgl. o.V., 2003b; o.S.
- ↑ Vgl. o.V., 2003b; o.S.
- ↑ Vgl. o.V., 2003b; o.S.
- ↑ Quelle: Bünning und Krause, 2006; S. 149
- ↑ Vgl. o.V., 2009r; o.S.
- ↑ Vgl. o.V., 2009s; o.S.
- ↑ Vgl. o.V., 2009r; o.S.
- ↑ Vgl. o.V., 2009t; o.S.
- ↑ Vgl. o.V., 2009u; o.S.
- ↑ Vgl. o.V., 2009k; o.S.
- ↑ Vgl. o.V., 2009s; o.S.
- ↑ Vgl. o.V., 2009u; o.S.
- ↑ Vgl. Shin, 2008; o.S.
- ↑ Vgl. Manson, 2009; o.S.
- ↑ Vgl. o.V., 1987; o.S.
- ↑ Vgl. o.V., 1987; S. 1
- ↑ Vgl. o.V., 1995, S. 1
- ↑ Vgl. o.V., 1994; S. 1
- ↑ Vgl. o.V., 1987; S. 9
- ↑ Vgl. o.V., 1987; S. 9
- ↑ Vgl. o.V., 1987; S. 36f
- ↑ Vgl. o.V., 1987; S. 32ff
- ↑ Vgl. Wang, 2009; o.S.
- ↑ Vgl. o.V., 2009v; o.S.
- ↑ Vgl. Wang, 2009; o.S.
- ↑ Vgl. Wang, 2009; o.S.
- ↑ Vgl. Wang, 2009; o.S.
- ↑ Vgl. Wang, 2009; o.S.
- ↑ Vgl. Wang, 2009; o.S.
- ↑ Vgl. Wang, 2009; o.S.
- ↑ Vgl. Wang, 2009; o.S.
- ↑ Vgl. o.V., 2005; S. 83
- ↑ Vgl. o.V., 1997, S. 4-10f
- ↑ Vgl. o.V., 1997, S. 4-13
- ↑ Vgl. Wang, 2009; o.S.
- ↑ Vgl. o.V., 2005; S. 83
- ↑ Vgl. o.V., 2005; S. 147
- ↑ Vgl. Woodhouse, 2001; S. 1
- ↑ Vgl. Woodhouse, 2001; S. 1
- ↑ Vgl. Rosenblum und Ousterhout, 1991; S. 1
- ↑ Vgl. Gal und Toledo, 2004; S. 20
- ↑ Vgl. Rosenblum und Ousterhoust, 1991; S. 1
- ↑ Vgl. Woodhouse, 2001; S. 5
- ↑ Vgl. Woodhouse, 2001; S. 5
- ↑ Vgl. Fridman, 2003; S. 6
- ↑ Quelle: Fridman, 2003; S. 7
- ↑ Vgl. Shmidt, 2002, S. 1
- ↑ Vgl. Shmidt, 2002, S. 2
- ↑ Vgl. Dan und Singer, 2003; S. 9
- ↑ Vgl. Fridman, 2003; S. 6
- ↑ Vgl. Dan und Singer, 2003; S. 9
- ↑ Vgl. Mellor, 2008; o.S.
- ↑ Vgl. Perridon und Steiner, 2007; Seite 28
- ↑ Vgl. Zantow, 2007; Seite 456
- ↑ Vgl. Ulrich B. Boddenberg (2008); o.S.
- ↑ Vgl. Narayanan, et. al., 2009; S. 6f
- ↑ Quelle: Narayanan, et. al., 2009; S. 6
- ↑ Vgl. Troppens, et. al., 2008; S. 43
10 Literaturverzeichnis
| Bitar, 2008 | Bitar, R.: "Deploying Hybrid Storage Pools"; SUN Microsystems; Santa Clara, 2008 |
| Boddenberg, 2008 | Boddenberg, U. B.: "Windows Server 2008"; http://openbook.galileocomputing.de/windows_server_2008/windows_server_2008_kap_15_001.htm#mj065fc642bab21cb57ba407aabe395962; Galileo Computing, Bonn, 2008 |
| Bünning und Krause, 2006 | Bünning, U., Krause, J.: "Windows Server 2003: Einrichtung und Administration von Unternehmensnetzen mit Standard und Enterprise Edition", 2. Auflage; Hanser Verlag; München, 2006 |
| Callaby, et. al., 1994 | Callaby, D. R., Dahlberg, D., Katti, R., Lorentz, R., Mitchell, W., Skorjamc, J.: "Solid State Memory Study, Final Report"; National Media Lab; St. Paul, 1994 |
| Chinner und Higdon, 2006 | Chinner, D., Higdon, J: "Exploring High Bandwidth Filesystems on Large Systems"; Silicon Graphics, Inc.; Fremont, 2006
http://oss.sgi.com/projects/xfs/papers/ols2006/ols-2006-paper.pdf; Stand: 10.06.2009 |
| Chang, 2008 | Chang, L.-P.: "Hybrid Solid-State Disks: Combining Heterogeneous NAND Flash in Large SSDs"; IEEE Computer Society Press; Soul, 2008 |
| Chiang, et. al., 1998 | Chiang, M.-L., Lee, P. C. H.; Chang, R.-C.: "Cleaning Policies in Mobile Computers Using Flash Memory"; National Chiao Tung University; Taipei, 1998;
http://www.iis.sinica.edu.tw/page/research/TechReport/tr1998/tr98005.ps.gz; Stand: 06.06.2009 |
| Cocker, 1999 | Cocker, R: Readme.html zu "Bonnie++ Benchmarks"
http://sourceforge.net/projects/bonnie/, Stand: 01.06.2009 |
| Coufal und Burr, 2002 | Coufal, H. und Burr, G. W.: "Optical data storage" aus "Principles, Potential, and Problems - Presented at the 2002 Conference on File and Storage Technologies"; San Jose, 2002
http://sunoptics.caltech.edu/~goffbo/papers/ITOchap.pdf; Stand: 14.06.2009 |
| Cox, 2009 | Cox, A.: "Serial Attached SCSI – 2.1"; ANSI INCITS; Washington, 2009 |
| Dan und Singer, 2003 | Dan, R. und Singer, R.: "Implementing MLC NAND Flash for Cost-Effective, High-Capacity Memory"; M-Systems Ltd.; Kfar Saba, 2003
http://www.data-io.com/pdf/NAND/MSystems/Implementing_MLC_NAND_Flash.pdf; Stand: 06.06.2009 |
| Fridman, 2003 | Fridman, A.: "TrueFFS 6.x Software Development Kit (SDK)"; M-Systems Ltd.; Kfar Saba, 2003
http://www.spezial.com/commercio/dateien/produktbeitraege/TrueFFS.pdf; Stand: 06.06.2009 |
| Gal und Toledo, 2004 | Gal, E. und Toledo, S.: "Algorithms and Data Structures for Flash Memories"; University of Tel-Aviv; Tel-Aviv, 2004
http://tau.ac.il/~stoledo/Pubs/flash-survey.pdf; Stand: 06.06.2009 |
| Gal und Toledo, 2005 | Gal, E. und Toledo, S.: "Mapping Structures for Flash Memories: Techniques and Open Problems"; University of Tel-Aviv; Tel-Aviv, 2005
http://tau.ac.il/~stoledo/Pubs/swste2005.pdf; Stand: 06.06.2009 |
| Garimella, 2006 | Garimella, N.: "Understanding and exploiting snapshot technology for data protection"; IBM developerWorks; Armonk, 2006
http://www.ibm.com/developerworks/tivoli/library/t-snaptsm1/index.html; Stand: 10.06.2009 |
| Goriop, 2009 | Goriop, R.: "Dateisysteme und Speichertechnologien von mySAP.com - System und Einsatzplanung"; HTBLA; Kaindorf, 2009
http://www.htl-kaindorf.ac.at/www2/Internet_EDVO/paedagogik/htbla_umsetzung/e_sep/mySAP_speichertechnologien.doc; Stand: 06.06.2009 |
| Hansen und Neumann, 2006 | Hansen, H.R. und Neumann, G.: "Wirtschaftsinformatik 2 – Informationstechnik", 9. Auflage; Lucius & Lucius; Stuttgart, 2005 |
| Hauksson und Ásmundsson, 2007 | Hauksson, A. G. und Ásmundsson, S.: "Data Storage Technologies"; Reykjavík University; Reykjavík, 2007
http://olafurandri.com/nyti/papers2007/DST.pdf; Stand: 06.06.2009 |
| Hufnagl, 2008 | Hufnagl, K.: "Die neue Leistungsformel: Power = i + p" in Hufnagl, M. (Hrsg): "Oxaion World", Ausgabe 2/2008; Wien, 2008
http://www.creapower.com/upload/firmenzeitungen/oxaion/firmenzeitung-11_pdf.pdf; Stand: 06.06.2009 |
| Hutsell, et. al., 2008 | Hutsell, W., Bowen, J., Ekker, N.: "Flash Solid-State Disk Reliability"; Texas Memory Systems; Huston, 2008
http://www.texmemsys.com/files/f000252.pdf; Stand: 06.06.2009 |
| Immink, 1997 | Immink, K.A.S: "Digital Versatile Disc"; The Institution of Electrical Engineers; London, 1997 |
| Johnson, 2006 | Johnson, C. III.: "MEMORANDUM FOR THE HEADS OF DEPARTMENTS AND AGENCIES - Protection of Sensitive Agency Information (M-06-16)"; Whitehouse; Washington D.C., 2006
http://www.whitehouse.gov/omb/memoranda/fy2006/m06-16.pdf; Stand: 06.06.2009 |
| Jones, 2008 | Jones, T.: "Anatomy of Linux Journaling File Systems"; IBM developerWorks; Armonk, 2008
http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux/l-journaling-filesystems/l-journaling-filesystems-pdf.pdf; Stand: 10.06.2009 |
| Kaiser, et. al., 2007 | Kaiser, U., Schwarz, A., Wiesendanger, R.: "Magnetic exchange force microscopy with atomic resolution"; Nature Weekly, Ausgabe 446, S. 522 - 527; London, 2007;
doi:10.1038/nature05617; Stand: 01.06.2009 |
| Karels, et. al., 1990 | Karels, M. J., McKusick, M. K., Bostic, K.: "A Pageable Memory Based Filesystem"; University of California; Berkeley, 1990 |
| Katcher, 1997 | Katcher, J: "A New File System Benchmark"; Network Appliance Inc; Sunnyvale, 1997
http://communities.netapp.com/servlet/JiveServlet/download/2609-1551/Katcher97-postmark-netapp-tr3022.pdf; Stand: 06.06.2009 |
| Mansuripur, 1998 | Mansuripur, M.: "The Physical Principles of Magneto-optical Recording"; Cambridge University Press; Cambridge, 1998 |
| Manson, 2009 | Manson, C.: "ssh optimised mode"; Gmane.org; 2009
http://article.gmane.org/gmane.comp.file-systems.btrfs/2602/match=ssd; Stand: 10.06.2009 |
| Masiewizc, 2004 | Masiewizc, J.: "ATA/ATAPI-7 V3"; ANSI INCITS; Washington; 2004
http://www.t13.org/Documents/UploadedDocuments/project/d1532v3r3f-ATA-ATAPI-7.pdf; Stand: 10.06.2009 |
| Mellor, 2008 | Mellor, C.: "The secret sauce in SanDisk's ExtremeFFS"; Situation Publishing Ltd.; London, 2008
http://www.theregister.co.uk/2008/11/07/sandisk_extremeffs_dram_buffer; Stand: 06.06.2009 |
| Narayanan, et. al., 2009 | Narayanan, D., Thereska, E., Donnelly, A., Elnikety, S., Rowstron, A.: "Migrating Server Storage to SSDs: Analysis of Tradeoffs"; Microsoft Research; Cambridge 2009
http://www.research.microsoft.com/~antr/MS/ssd.pdf; Stand: 14.06.2009 |
| Norcott, 1998 | Norcott, W.D.: Dokumentation zu "IOZone", 1998
http://www.iozone.org/docs/IOzone_msword_98.pdf; Stand: 06.06.2009 |
| Ogawa und Nakajima, 1992 | Ogawa, H. und Nakajima, H.: "Compact disc technology"; IOS Press; Amsterdam, 1992 |
| Pachuchiy, 2007 | Pachuchiy, Y.: "Exploring the ntfsprogs toolset" in Casad, J. (Hrsg): "Linux Magazine", Ausgabe 74, S. 24-27; München, 2007 |
| Perridon und Steiner, 2007 | Perridon, L. und Steiner, M.: "Finanzwirtschaft der Unternehmung", 14. Auflage; Verlag Vahlen; München, 2007 |
| Pohlmann, 1992 | Pohlmann, Ken C.: "The compact disc handbook"; Oxford University Press; Oxford, 1992 |
| Rosenblum und Ousterhout, 1991 | Rosenblum, M und Ousterhout, J. K.: "The Design and Implementation of a Log-Structured File System"; University of California; Berkeley, 1991 |
| Shimada, et. al., 2009 | Shimada, K., Ishii, T., Ide, T.: "High Density Recording using Monocular Architecture for 500GB Consumer System"; inPhase Technologies; Longmont, 2009
http://www.inphase-technologies.com/downloads/pdf/technology/ODS2009_high_density_ver20090507.pdf; Stand: 07.06.2009 |
| Shin, 2008 | Shin, D.: "btrfs and Solid State Disks (SSD)"; Gmane.org; 2008
http://article.gmane.org/gmane.comp.file-systems.btrfs/449/match=ssd; Stand: 10.06.2009 |
| Shmidt, 2002 | Shmidt, D.: "TrueFFS Wear-Leveling Mechanism"; M-Systems Ltd.; Kfar Saba, 2002
http://www.dataio.com/pdf/NAND/MSystems/TrueFFS_Wear_Leveling_Mechanism.pdf; Stand: 06.06.2009 |
| Solter et al., 2009 | Solter, N.A., Jelinek, G., Miner, D.: "OpenSolaris Bible"; Wiley Publishing Inc.; Indianapolis, 2009 |
| Sweeney et. al., 1996 | Sweeney, A., Doucette, D., Hu, W., Anderson, C., Nishimoto, M., Peck, G.: "Scalability in the XFS File System"; Silicon Graphics Inc; Fremont, 1996 |
| Tanenbaum, 2006 | Tanenbaum, A.S.: "Computerarchitektur", 5. Auflage; Pearson; Stuttgart, 2006 |
| Troppens, et. al., 2008 | Troppens, U., Erkens, R., Müller, W.: "Speichernetze - Grundlagen und Einsatz von Fibre Channel SAN, NAS, iSCSI und InfiniBand", 2. aktualisierte und erweiterte Auflage; dpunkt.verlag; Heidelberg, 2008 |
| Wang, 2009 | Wang, W: "Introduction to Universal Disk Format (UDF)",
http://homepage.mac.com/wenguangwang/myhome/udf.html; Stand: 23.05.2009 |
| Weißenborn, 2008 | Weißenborn, R: "Die Zukunft flasht"; Spiegel Online; Hamburg, 2008
http://www.spiegel.de/netzwelt/tech/0,1518,559636,00.html; Stand: 18.05.2009 |
| Werner und Schneider, 2000 | Werner, D. und Schneider, U.: "Taschenbuch der Informatik", 3. Auflage; Hanser; München, 2000 |
| Woodhouse, 2001 | Woodhouse, D.: "JFFS : The Journalling Flash File System"; Red Hat Inc.; Raleigh, 2001
http://sources.redhat.com/jffs2/jffs2.pdf; Stand: 06.06.2009 |
| Zantow, 2007 | Zantow, R.: "Finanzwirtschaft der Unternehmung", 2. Auflage; Pearson Studium; München, 2007 |
| Zhang, et al., 2006 | Zhang, X. Du, D., Hughes, J., Kavuri, R.: "HPTFS: A High Performance Tape File System"; University of Minnesota; Minnesota, 2006 |
| o.V., 1987 | o.V.: ECMA-119: "Volume and File Structure of CDROM for Information Interexchange"; ECMA; Genf, 1987
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf, Stand: 25.05.2009 |
| o.V., 1994 | o.V.: "Rockridge Interexchange Protocol", Draft Standard 1.12; Institute of Electronical and Electronics Engineers Inc; New York, 1994
ftp://ftp.ymi.com/pub/rockridge/rrip112.ps; Stand: 25.05.2009 |
| o.V., 1995 | o.V.: "Joliet Specification"; Microsoft; Redmond, 1995
http://bmrc.berkeley.edu/people/chaffee/jolspec.html, Stand: 25.05.2009 |
| o.V., 1997 | o.V.: ECMA-167: "Volume and File Structure for Write-Once and Rewritable Media using Non-Sequential Recording for Information Interexchange"; ECMA; Genf, 1997
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-167.pdf, Stand: 23.05.2009 |
| o.V., 2000 | o.V.: "Novell Netware 5.1 Traditional File Service Administration Guide"; Novell Inc.; Düsseldorf, 2000 |
| o.V., 2003a | o.V.: "SuSE Linux Administrationshandbuch; Novell/SuSE"; Düsseldorf, 2003 |
| o.V., 2003b | o.V.: "How NTFS works"; Microsoft; Redmont, 2003
http://technet.microsoft.com/en-us/library/cc781134.aspx; Stand: 10.06.2009 |
| o.V., 2004a | o.V.: White Paper: "Serial Attached SCSI"; Enterprise Management Associates; Boulder, 2004 |
| o.V., 2004b | o.V.: White Paper: "Blu-Ray Disc Format"; Blu-Ray Disc Foulders; Universal City, 2004
http://www.blu-raydisc.com/Assets/Downloadablefile/3_filesystem-15265.pdf; Stand: 06.06.2009 |
| o.V., 2004c | o.V.: "The Open Group Base Specifications Issue 6 IEEE Std 1003.1"; The IEEE and The Open Group; San Francisco, 2004
http://www.opengroup.org/onlinepubs/009695399/; Stand: 06.06.2009 |
| o.V., 2005 | o.V.: "Universal Disk Format Specification", Rev. 2.60; OSTA.org; Cupertino, 2005
http://www.osta.org/specs/pdf/udf260.pdf, Stand: 23.05.2009 |
| o.V., 2006 | o.V.: ECMA-375: "Case for 120 mm HVD-ROM disk"; ECMA; Genf, 2006
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-375.pdf; Stand: 06.06.2009 |
| o.V., 2007a | o.V.: ECMA-377: "Information Interchange on Holographic Versatile Disc (HVD) Recordable Cartridges – Capacity: 200 Gbytes per Cartridge"; ECMA; Genf, 2007
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-377.pdf; Stand: 01.06.2009 |
| o.V., 2007b | o.V.: ECMA-378: "Information Interchange on Read-Only Memory Holographic Versatile Disc (HVD-ROM) – Capacity: 100 Gbytes per disk"; ECMA; Genf, 2007
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-378.pdf; Stand: 06.06.2009 |
| o.V., 2007c | o.V.: "Overview of FAT, HPFS, and NTFS File Systems"; Microsoft; Redmont, 2007
http://support.microsoft.com/kb/100108/en-us; Stand: 10.06.2009 |
| o.V., 2008a | o.V.: ECMA-382: "120mm (8,54 Gbytes per side) and 80mm (2,66 Gbytes per side) DVD Recordable Disk for Dual Layer (DVD-R for DL)"; ECMA; Genf, 2008;
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-382.pdf; Stand: 01.06.2009 |
| o.V., 2008b | o.V.: IT-Grundschutz-Kataloge, Maßnahmenkatalog M 4.29: "Einsatz eines Verschlüsselungsproduktes für tragbare IT-Systeme"; Bundesamt für Sicherheit in der Informationstechnik; Bonn, 2008 |
| o.V., 2008c | o.V.: IT-Grundschutz-Kataloge, Maßnahmenkatalog M 2.167: "Sicheres Löschen von Datenträgern", Bundesamt für Sicherheit in der Informationstechnik; Bonn, 2008 |
| o.V., 2008d | o.V.: White Paper: "Solaris ZFS Enables Hybrid Storage Pools"; SUN Microsystems; Santa Clara, 2008
http://www.sun.com/software/solaris/pdf/solariszfs_solutionbrief.pdf; Stand: 10.06.2009 |
| o.V., 2009a | o.V.: Data Sheet: "Maxtor DiamondMax 23"; Seagate; Scotts Valley, 2009
http://www.seagate.com/docs/pdf/datasheet/disc/ds_dmax_23.pdf; Stand: 10.06.2009 |
| o.V., 2009b | o.V.: "Frequently Asked Questions"; InPhase Technologies; Longmont, 2009
http://www.inphase-technologies.com/news/faq.asp; Stand: 06.06.2009 |
| o.V., 2009c | o.V.: "Products: tapestry 300r"; InPhase Technologies;
http://www.inphase-technologies.com/products/default.asp?tnn=3; Stand: 06.06.2009 |
| o.V., 2009d | o.V.: "HVD - Technologie"; HSD Forum; Tokio, 2009;
http://hvd-forum.org/abouthvd/technology.html; Stand: 06.06.2009 |
| o.V., 2009e | o.V.: Pressemitteilung: "Western Digital präsentiert erste 2-TB-Festplatte der Welt2"; Western Digital; München, 2009
http://www.westerndigital.com/de/company/releases/Pressrelease.asp?release=20090127; Stand 18.05.2009 |
| o.V., 2009f | o.V.: "Portrait eines Erfolges – Von der einzigartigen Entdeckung zum Lösungsanbieter für Produktschutz"; Tesa Scribos; Hamburg, 2009
http://www.tesa-scribos.com/deu/company/profile, Stand: 18.05.2009 |
| o.V., 2009g | o.V.: LVM Howto: "2. What is Logical Volumen Management"; Rackable Systems Inc.; Fremont, 2009
http://www.tldp.org/HOWTO/LVM-HOWTO/; Stand: 01.06.2009 |
| o.V., 2009h | o.V.: LVM Howto: "11.9. Extending a logical volume"; Rackable Systems Inc.; Fremont, 2009
http://www.tldp.org/HOWTO/LVM-HOWTO/; Stand: 01.06.2009 |
| o.V., 2009i | o.V.: LVM Howto: "11.10. Reducing a logical volume"; Rackable Systems Inc.; Fremont, 2009
http://www.tldp.org/HOWTO/LVM-HOWTO/; Stand: 01.06.2009 |
| o.V., 2009j | o.V.: "Solaris ZFS Administration Guide – Deutsche Edition"; SUN Microsystems; Santa Clara, 2009 |
| o.V., 2009k | o.V.: "Using BtrFS with Multiple Devices",
http://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices; Stand: 01.06.2009 |
| o.V., 2009l | o.V.: FreeBSD Handbook, Kapitel 14.12: "File System Access Control Lists"; The FreeBSD Foundation; Boulder, 2009
http://www.freebsd.org/doc/en/books/handbook/fs-acl.html; Stand: 01.06.2009 |
| o.V., 2009m | o.V.: "What Are Security Descriptors and Access Control Lists?"; Microsoft Technet; Redmont, 2009
http://technet.microsoft.com/en-us/library/cc783702(WS.10).aspx; Stand: 01.06.2009 |
| o.V., 2009n | o.V.: "XFS Old News"; Rackable Systems Inc.; Fremont, 2009
http://www.xfs.org/index.php/OLD_News; Stand: 01.06.2009 |
| o.V., 2009o | o.V.: "XFS Users"; Rackable Systems Inc.; Fremont, 2009
http://oss.sgi.com/projects/xfs/users.html; Stand: 01.06.2009 |
| o.V., 2009p | o.V.: "XFS support discarding of unused sectors"; Rackable Systems Inc., Fremont, 2009
http://xfs.org/index.php/Support_discarding_of_unused_sectors; Stand: 01.06.2009 |
| o.V., 2009q | o.V.: "NTFS-3G Stable Read/Write Driver";
http://www.ntfs-3g.com; Stand: 10.06.2009 |
| o.V., 2009r | o.V.: "Startseite zu BtrFS"; Oracle; Redwood, 2009
http://btrfs.wiki.kernel.org/index.php/Main_Page; Stand: 01.06.2009 |
| o.V., 2009s | o.V.: "Design von BtrFS"; Oracle; Redwood, 2009
http://btrfs.wiki.kernel.org/index.php/Btrfs_design; Stand: 01.06.2009 |
| o.V., 2009t | o.V.: "Conversion from Ext3"; Oracle; Redwood, 2009
http://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3; Stand: 01.06.2009 |
| o.V., 2009u | o.V.: "BtrFS - Frequently Asked Questions"; Oracle; Redwood, 2009
http://btrfs.wiki.kernel.org/index.php/FAQ; Stand: 06.06.2009 |
| o.V., 2009v | o.V.: "Specifications: Universal Disk Format (UDF)"; OSTA.org, Cupertino, 2009
http://www.osta.org/specs/, Stand: 23.05.2009 |












