RE: Neue CompactFlash-Revision: CF5.0 für 128 Petabyte

#1 von matthiaspaul , 25.02.2010 14:51

Hallo zusammen,

die Compact Flash Association (CFA) hat anläßlich der PMA 2010 eine neue Revision des CompactFlash-Standards vorgestellt, die mit den bisherigen Beschränkungen bricht:

Karten und Lesegeräte nach dem CF5.0-Standard unterliegen jetzt nicht mehr der "drohenden" Kapazitätsbegrenzung auf maximal 128 GiB (137 GB), sondern können bis zu 128 PiB (144 PB) (entsprechend 134217728 GiB bzw. 131072 TiB) groß werden. Dafür wurde die Spezifikation um die Unterstützung für LBA-48 (mit 48-Bit-Sektoradressierung) erweitert. Deren Unterstützung ist im Standard vorgeschrieben, dafür wird durch die Kompatibilität mit dem ATA-Kommandosatz nach ATA-6/ACS-2 eine Adressierung über CHS in Zukunft optional. Bisherige CF-Karten unterstützten noch kein LBA-48, sondern nach ATA-4 "nur" LBA-28- und CHS-Zugriffe, zumindest auf dem Papier. In der Realität gibt es (leider) auch jetzt schon Karten, die keine CHS-Zugriffe mehr unterstützen, was allerdings immer wieder zu Kompatibilitätsproblemen führt. (Klassische Systeme besitzen eine Schranke bei 8 GiB für CHS-Zugriffe, darüberhinaus sind LBA-Zugriffe notwendig. LBA-28 reicht bis 128 GiB, das inoffizielle LBA-32 bis 2 TiB, LBA-48 bis 128 PiB.) Nur ältere Betriebssysteme von vor 1995 sind auf die Möglichkeit des Zugriffs über CHS angewiesen, würden aber die zukünftigen Kapazitäten sowieso nicht ausnutzen können. Insofern ist der mögliche Verzicht auf CHS in Zukunft kein großes Problem. Selbst späte DOS-Versionen (MS-DOS ab 7.0, PC DOS ab 7.1, DR-DOS ab 7.04) unterstützen bereits LBA-Zugriffe.

Um schnellere Zugriffe auf sequentiell hintereinanderliegende Daten zu ermöglichen, werden jetzt im Rahmen von LBA-48 Multisektortransfers von bis zu 32 MiB (65536 Sektoren á 512 Bytes) am Stück unterstützt. Im Rahmen von LBA-28 waren maximal 128 KiB (256 Sektoren á 512 Bytes) pro Befehl möglich. Da Flashspeicher intern sowieso nicht in Sektoren á 512 Bytes organisiert sind, sondern in viel größeren Blöcken (2 KiB und mehr), mußten selbst zum Lesen eines einzigen Sektors mit 512 Bytes intern immer viel größere Blöcke gelesen oder geschrieben werden, so daß es mit großen Performanceverlusten einherging, wenn man Sektoren einzeln adressierte. Zwar läßt sich das nicht immer vermeiden, aber gerade dann, wenn es auf maximale Geschwindigkeit ankommt, wie etwa beim Wegschreiben der Daten von großen Bildern, kann man durch Multisektortransfers auch ohne die eigentliche Transferrate erhöhen zu müssen einen deutlichen Geschwindigkeitsgewinn erzielen, indem man einfach den Overhead reduziert. Und da die zu schreibenden Sektoren in der Regel sowieso direkt hintereinanderliegen, wenn man neue Dateien auf ein Medium mit frisch formatiertem FAT-Dateisystem schreibt, auf dem noch nichts gelöscht wurde (bis auf die gelegentlichen Änderungen in den Verzeichniseinträgen und der FAT), bietet es sich an, möglichst große Speicherbereiche am Stück wegschreiben zu können. Um Multisektortransfers anstoßen zu können, muß der Dateisystemtreiber des Hostbetriebssystems allerdings neben den eigentlichen Daten auch mehr oder weniger große Teile der FAT im Speicher vorhalten, um genügend große freie Bereiche sozusagen aus der "Vogelperspektive" heraus identifizieren zu können. Insofern werden Multisektortransfers mit mehr als ein paar wenigen Kilobyte (typisch dafür ist eher die Clustergröße, also theoretisch 0,5 bis 64 KiB, in der Praxis eher 4 KiB bis 32 KiB) nur unter Systemen Vorteile bringen, die über sehr viel RAM-Speicher und entsprechend angepaßte Dateisystemtreiber verfügen. Benötigt man zum Cachen der kompletten FAT bei einem FAT16-Laufwerk beliebiger Größe gerade mal 128 KiB, so wären dazu bei FAT32 theoretisch bis zu 1 GiB notwendig - illusorisch auf einem Embedded System. Ein Dateisystemtreiber, der mit deutlich niedrigeren Speicheranforderungen dennoch auf höchsten Durchsatz kommen möchte, wird also vorab die FAT "scannen" und sich die großen freien Bereiche in einer internen "Karte" vermerken ohne gleich die FAT selbst zwischenzupuffern. Mit dem daraus gewonnenen Wissen kann er dann später Daten- und FAT-Bereiche zeitlich weitestgehend unabhängig voneinander beschreiben und so zumindest für die Daten mit riesigen Multisektortransfers arbeiten, ohne dabei "versehentlich" andere Dateien zu überschreiben.

Eine weitere Neuerung betrifft definierbare Geschwindigkeitsprofile, die es z.B. in Videoanwendungen ermöglichen, zwischen Kamera und Karte bestimmte garantierte Durchsatzraten individuell "auszuhandeln", um so Aussetzer durch Schreibpausen während des Filmens zu vermeiden.

Weitere Änderungen betreffen das elektrische Interface, dessen Spannungspegel jetzt JEDEC-konform angepaßt wurden. Das PATA-Interface wird (offenbar) beibehalten, aber vermutlich dürfte damit die Unterstützung für 5,0V-Karten wegfallen. Ob neben 3,3V jetzt auch noch weitere, niedrigere Spannungen unterstützt werden, ist mir im Moment noch nicht bekannt. Diese elektrischen Änderungen erfordern neue Kartenleser, allerdings wird der CF5.0-Spezifikation nach offenbar die Rückwärtskompatibilität der Karten auch mit älteren Lesern beibehalten; vermutlich werden dann einfach die allerschnellsten Betriebsmodi nicht unterstützt.

Neben der SATA-basierten Lösung CFast 1.0, die seit 2008 als Compact Flash-Nachfolger gehandelt wurde, gibt es jetzt also auch eine PATA-basierte Erweiterung des Standards, die direkt steckkompatibel zur bisherigen CompactFlash-Karte bleibt. Ich hatte, ehrlich gesagt, nicht mehr damit gerechnet, daß CF5.0 noch verabschiedet würde, obwohl die Erweiterung doch so naheliegend war, da die notwendigen Änderungen minimal ausfallen und der altgediente CF-Standard so wieder auf Jahre hinaus zukunftsfähig hätte gemacht werden können. Insofern finde ich die Verabschiedung des neuen Standards höchst begrüßenswert; CompactFlash bleibt so der mit Abstand leistungsfähigste Speicherkartenstandard und verweist in der neuen Revision zu sich selbst inkompatible Krücken wie SDXC und Memory Stick XC, die gerade dabei waren, Compact Flash zumindest bezüglich der theoretischen Grenzwerte zu überholen (ohne daß diese Grenzen in der Praxis schon je erreicht worden wären), wieder auf die abgeschlagenen hinteren Plätze. Ob letztlich CFast (SATA) oder CF5.0 (PATA) langfristig das Rennen macht, CF5.0 setzt die technischen Grenzwerte so hoch, daß das Format aus anderen Gründen lange abgelöst worden sein dürfte, bevor diese Marken je erreicht werden, es wird also zu einem langsamen Auslaufen des Standards in fünf, zehn oder vielleicht auch fünfzehn Jahren kommen, nicht zu einem abrupten Ende binnen der nächsten paar Jahre. So besteht nun erstmal wieder ziemlicher "Investitionsschutz" für heutige Käufer von CompactFlash-Karten. Lediglich bei den externen Lesegeräten sollte man möglichst bald darauf achten, daß diese CF5.0 kompatibel sind. Entsprechende Geräte werden mit einem speziellen "CF5"-Logo gekennzeichnet sein.

Randbemerkung: Bisher konnte ich auch noch nichts zu einem vorgeschriebenen Dateisystem für CompactFlash-Karten nach CF5.0 finden, was ich ebenfalls sehr begrüßenswert finde. Im Gegensatz dazu wird bei SDXC und MSXC das proprietäre, patentierte und lizenzpflichtige Microsoft-Dateisystem exFAT fest im Standard vorgeschrieben. Die Interna von exFAT sind allerdings nicht offengelegt, das System wird bisher überhaupt nur von ganz wenigen Betriebssystemen unterstützt, und es wird dafür in freien (und älteren) Betriebssystemen aus rechtlichen und technischen Gründen vermutlich auch niemals Unterstützung geben. Mit dem frei implementierbaren FAT32-Dateisystem kann man zwar keine vollen 128 PiB adressieren, aber mit ein paar Tricks doch sehr weit über die von Microsoft empfohlenen 32 GiB hinausgehen, so daß es Sinn macht, auch weiterhin FAT32 auf CF5.0-Karten zu verwenden. (Einige Windows-Implementierungen unterstützten FAT32 nur bis 32 GiB Volume-Größe, aber vom Aufbau des Dateisystems selbst her sind eigentlich bis zu 2 TiB möglich, als Nicht-Boot-Medium bis zu 8 TiB und mit 64 KB-Clustern bis zu 16 TiB, mit FAT32B (derzeit nur von OEM DR-DOS unterstützt, aber als Dateisystem frei) sogar 128 TiB (mit verschiedenen Tricks sogar bis 128 PiB).)

Viele Grüße,

Matthias


"All the important human advances that we know of since historical times began
have been due to individuals of whom the majority faced virulent public opposition."
--Bertrand Russell

http://www.mi-fo.de/forum/viewtopic.php?t=13448 (Minolta Forum Thread Index)

Dateianlage:
Aufgrund eingeschränkter Benutzerrechte werden nur die Namen der Dateianhänge angezeigt Jetzt anmelden!
f198t26128p257175n1.pdf f198t26128p257175n2.pdf f198t26128p257175n3.pdf f198t26128p257175n4.pdf

matthiaspaul  
matthiaspaul
Beiträge: 14.595
Registriert am: 08.06.2004


RE: Neue CompactFlash-Revision: CF5.0 für 128 Petabyte

#2 von wus , 27.02.2010 12:30

Ich finde vor allem gut dass der Schritt die neue Grenze anders als zuletzt bei SD -> SDHC -> SDXC nicht nur wenige Zweierpotenzen höher setzt sondern wirklich einen Standard definiert der nach allem was man momentan so absehen kann wenigstens 10 Jahre Bestand haben kann. Das verdeutlicht auch den Profi-Anspruch, ganz im Gegensatz zu SD und Memory Stick die ich mittlerweile beide so einschätze dass hier bewusst regelmäßig relativ knappe neu Grenzen definiert werden so dass den Konsumenten nach 2 - 3 Jahre mehr oder weniger automatisch neues Geld aus der Tasche gezogen werden kann, weil die die Speicherkarten verwendenden Gerätschaften nicht mehr mit den dann schon wieder neuen Speichermedien verwendet werden können.


leave nothing but footprints, take nothing but memories


wus  
wus
Beiträge: 220
Registriert am: 28.06.2007


RE: Neue CompactFlash-Revision: CF5.0 für 128 Petabyte

#3 von weberhj , 27.02.2010 12:55

ZITAT(matthiaspaul @ 2010-02-25, 14:51) die Compact Flash Association (CFA) hat anläßlich der PMA 2010 eine neue Revision des CompactFlash-Standards vorgestellt...[/quote]
Danke Matthias, ein klasse Artikel von dir.

BG Hans


In the mind of Minolta...


weberhj  
weberhj
Beiträge: 1.117
Registriert am: 30.03.2006


RE: Neue CompactFlash-Revision: CF5.0 für 128 Petabyte

#4 von matthiaspaul , 05.12.2010 02:01

Am 2010-11-18 hat die CFA zum fünfzehnjährigen Bestehen eine weitere Revision des CF-Kartenstandards vorgestellt und ihr erstaunlicherweise direkt eine neue Hauptversionsnummer spendiert - CF 6.0 -, obwohl die Erweiterungen zwar absolut sinnvoll, aber eigentlich nur marginal sind. (Ich hätte sie von daher eher "CF 5.1" genannt, deshalb hänge ich das mal an den CF 5.0-Thread dran.)

Als wichtigste Neuerung definiert CF 6.0 einen neuen UDMA Modus 7 für bis zu 167 MB/s über das bisherige PATA-Interface - das war ein Punkt, der der CF 5.0 Spezifikation, mit der LBA-48 Unterstützung für extrem große Medien von bis zu 128 PiB nachgereicht wurde, noch fehlte.

Damit ist CF nun voll auf der Höhe der Zeit und wird noch für Jahre ausreichende Geschwindigkeit und für noch längere Zeiträume ausreichende Speicherkapazitäten bieten. Das PATA-Interface ist nun allerdings elektrisch endgültig am Anschlag, für weitergehende Geschwindigkeitssteigerungen müßte man auf eine serielle differentielle Datenübertragung ausweichen, wie sie z.B. SATA bietet (derzeit bis 300 MB/s).

Leider ist der bereits existierende SATA-basierte CFast-Standard nicht steckkompatibel mit CF-Karten. Die Adaption von SATA war nur folgerichtig, aber aus meiner Sicht hätte man CFast voll in den bestehenden CF-Kartenstandard integrieren sollen, indem einige der bisherigen Leitungen eine Doppelfunktion als SATA-Leitungspärchen bekommen hätten und Karte und Kartenleser bei Bedarf von PATA auf SATA umgeschaltet hätten. Auf diese Weise hätten sich CFast-Karten auch in herkömmlichen CF-Lesern lesen und schreiben lassen, nur halt nicht ganz so schnell - aber von langsam kann man bei Übertragungsraten von mehr als 100 MB/s nun auch nicht wirklich sprechen... Wie auch immer, volle Steckkompatibilität (statt nur Kompatibilität auf logischer Ebene im Betriebssystem) hätte der Verbreitung von CFast sicherlich geholfen.

Weitere Neuerungen der CF 6.0-Spezifikation betreffen Erweiterungen auf Kommandoebene:

Ein neuer Sanitize-Löschbefehl gemäß INCITS T13 ACS-2 erlaubt ein schnelles und (relativ) sicheres blockweises Löschen des NAND-Speichers.

Über eine Verfeinerung des TRIM-Befehls (Trim Usage Guidelines) kann eine bessere Schreibperformance erreicht werden.

Optional erlauben die Karten nun auch die Definition eines Temperaturprofils, über das eine gegebene Karten- und Kamerakombination aushandeln kann, ob sie unter bestimmten Extremtemperaturen noch arbeiten kann oder sicherheitshalber die Arbeit verweigert.

http://compactflash.org/2010/cf-6-0-introd...e-enhancements/

Viele Grüße,

Matthias


"All the important human advances that we know of since historical times began
have been due to individuals of whom the majority faced virulent public opposition."
--Bertrand Russell

http://www.mi-fo.de/forum/viewtopic.php?t=13448 (Minolta Forum Thread Index)

Dateianlage:
Aufgrund eingeschränkter Benutzerrechte werden nur die Namen der Dateianhänge angezeigt Jetzt anmelden!
f198t26128p269973n1.pdf

matthiaspaul  
matthiaspaul
Beiträge: 14.595
Registriert am: 08.06.2004


   


  • Ähnliche Themen
    Antworten
    Zugriffe
    Letzter Beitrag
| 2002- © so-fo.de | minolta-forum.de |
Xobor Einfach ein eigenes Forum erstellen
Datenschutz