Die COW Verwirrung

Wir schreiben das recht frische Jahr 2012. Das heisst ich habe nur noch knappe 12 Monate um eine Verwirrung aus der Welt zu räumen, die mich bereits die letzten 12 Jahre begleitet. Aber nachdem ich lang genug in der IT bin, glaube ich, dass auch die Mayas von Counter Overflows nicht verschont waren und es sich nicht um den Weltuntergang, sondern nur um das Y2K-Problem der Maya-Zeitrechnung handelt.

Es hat daher wohl nachhaltigen Nutzen, die Verwirrung der Storage-Industrie um den Begriff Copy-On-Write (COW) zu beleuchten. Hier mein Versuch:

Copy-on-Write (COW) im Memory Management

Das Copy-On-Write Verfahren kommt ursprünglich aus dem Memory Management und beschreibt eine Technik, die dort üblicherweise vom Virtual Memory Management (VMM) genutzt wird, um Hauptspeicher effizienter zu nutzen. Grob gesagt wird bei einem klassischen Prozessmodell ein neuer Prozess erzeugt, indem der Elternprozess geclont wird. Der neue Prozess hat einen privaten virtuellen Adressraum, der zunächst aus Zeigern auf die physischen Speicherblöcke des Elternprozesses besteht. Erst wenn einer der beiden Prozesse seinen Speicher ändert, wird eine Kopie des Speicherblocks auf einen neuem physischen Block erstellt, der virtuelle Zeiger umgebogen und die Modifikation ausgeführt. Das führt dazu, dass die Prozesse sich gleiche Blöcke teilen und nur die Differenzblöcke zusätzlich gespeichert werden müssen. Der neue Block wird immer an eine neue, leere Stelle geschrieben.

Copy-on-Write in der Storage-Welt

In der Storage-Industrie wurde der Begriff Copy-On-Write bis vor einigen Jahren für ein Verfahren zum Erstellen von Snapshot-Kopien genutzt. Dabei baut ein klassisches Storage-System einen Snapshot, in dem es beim Überschreiben einer durch Snapshots gesicherten LUN den alten Datenblock erst wegkopiert (oft in einen extra zu definierenden, dedizierten Snapshot Bereich), bevor es den neuen Block an die ursprüngliche Stelle schreibt. Natürlich ist dieses Verfahren nicht das schnellste, da für jeden zu schreibenden Block ein Lese- und zwei Schreib-IOs stattfinden müssen. Jeder Schreib-IO erzeugt 3 IOs. Auch hier werden gleiche Blöcke zwischen der LUN und ihren Snapshots geteilt, Differenzblöcke werden aber in den Snapshot verschoben. Mehrere Snapshots auf einer LUN erhöhen bei manchen Systemen den Aufwand zusätzlich.

Write Anywhere

Moderne, virtualisierende Systeme wie NetApp's WAFL machen das anders. Wird ein Block überschrieben, wird der neue Block einfach an eine freie Stelle geschrieben und der virtuelle Zeiger angepasst. Daher auch der Name "Write Anywhere File Layout". Es erzeugt einen Schreib-IO versus 3 IOs beim COW-Verfahren. Man nennt Filesysteme, die nach diesem Prinzip funktionieren, auch oft log-structured Filesystems.

Die SNIA beschreibt diese Verfahren übrigens recht gut in folgendem Dokument: http://www.snia.org/sites/default/education/tutorials/2007/spring/data-management/Disk-based_Restoration_Technologies.pdf , Seite 28-32. WAFL benutzt nach dieser Definition Write Anywhere (surprise, surprise).

Wenn ich mich bei Kollegen umhöre, verbinden die meisten mit COW das langsame, drei IOs erzeugende Verfahren. Unser Tribal Knowledge sagt: "COW ist lahm, WAFL macht es besser".

Der Sündenfall

Wo ist also das Problem? In den letzten Jahren wurde der Begriff COW-Filesystem immer öfter für Systeme benutzt, die nach der SNIA Beschreibung eigentlich Write Anywhere Filesysteme sind. COW wird also einerseits für die langsamen 3 IO-Systeme als auch für die flinken Write Anywhere Systeme benutzt. Wenn man nun auf jemanden trifft, der das jeweils andere Verfahren unter diesem Begriff versteht, führt das schnell zu fundamentalen Irrtümern.

Wie kam es dazu? In meiner Wahrnehmung hat die Verwirrung mit dem Release von ZFS angefangen. Als erstes generelles Filesystem hat ZFS die meisten Funktionen des kommerziell erfolgreichsten Write Anywhere Filesystems (NetApp's WAFL) kopiert und durch den Open Source Ansatz viel Hoffnung genährt, dass diese Funktionalität schnell Standard in allen relevanten Systemen wird (was nicht geschehen ist). Sprich: Während WAFL in NetApp Systemen eher unscheinbar unter der Motorhaube treu seine Dienste leistete, wurde es durch ZFS auf einmal sexy über Filesysteme, ihre Features und ihre Funktion zu sprechen.

Wenn man nun auf die Funktionsweise und die Nomenklaturen in ZFS sieht, gewinnt man den Eindruck, die Entwickler hatten eher einen VMM- anstatt eines Storage-Backgrounds. Einige Konzepte erinnern mehr an ein VMM (z.B. Slabs) als an Storage. So ist es auch nicht verwunderlich, das die Entwickler - vermutlich in mangelnder Kenntnis des Begriffes "Write Anywhere" oder "log structured" - den ihnen vertrauten und ein ähnliches Konzept beschreibenden Ausdruck Copy-On-Write wählten. Seitdem wird ZFS als COW Filesystem beschrieben. BTRFS hat dieses Wording später übernommen. Das hat dazu geführt, dass log-structured Filesysteme mittlerweile von vielen Menschen Copy-On-Write genannt werden, jedoch NetApp als Marktführer in Deutschland den Begriff COW anders nutzt. Und voilà, die Verwirrung ist komplett, wir reden womöglich alle aneinander vorbei …

So what?

Ist es nun wichtig, welcher Begriff korrekter ist als der andere? Ob wir log-structured Filesysteme Write Anywhere oder COW nennen? Ich denke nein. Ist es wichtig, dass mein Gegenüber versteht was ich meine, wenn ich COW benutze? Auf jeden Fall, ja!

Wie lösen wir dieses Missverständnis auf?

Die meisten meiner Kollegen würden gerne weiter COW für das langsame, unter dem obigen SNIA Link beschriebene Verfahren benutzen. Jedoch ist sich die SNIA wohl auch nicht mehr so 100% sicher, die COW Definition liest sich eher wie Write Anywhere. Und in Wikipedia steht unter ZFS und BTRFS auch immer COW-Filesystem. Ich glaube, das Kind bekommen wir nicht aus dem Brunnen.

Oder wir lassen COW und Write Anywhere einfach aussen vor und weichen auf "log-structured" aus, klingt aber ziemlich nerdy. Und wie nennen wir eigentlich das lahme 3 IO-Verfahren, das früher COW hieß? Move-on-Write (MOW)? Oder gleich Every Modify Copies?

Zumindest sollten wir alle in Zukunft mit dem Begriff Copy-On-Write Filesystem vorsichtiger umgehen und uns gewahr sein, dass unser Gegenüber genau das Gegenteil verstehen könnte …

Frohes 2012

Comments
New Contributor

Nachtrag: Ich wurde auf einen validen Punkt hingeweisen: log-structured Filesysteme sind nicht automatisch write anywhere. Zwar sind heute alle bekannten log-structured Filesysteme Write Anywhere, das muss aber nicht zwangslaeufig so sein. Log-structured betrifft die Art und Weise wie die Writes gesammelt werden, bevor die Write Allocation stattfindet. Die Write Allocation ist dann Write Anywhere oder eben nicht. Es sind aber auch log-structured Filesysteme denkbar, die eine andere Write Allocation Strategie nutzen.

Wenn mich jemand auf das leidige Thema COW anspricht dann erkläre ich es so:

Others create a Copy-on-Write

Netapp leaves a Copy-on-Write (... and writes new/modified data elsewhere)

So darf jeder in der Diskussion COW verwenden und niemand verliert sein Gesicht :-)

Eine ähnliche Verwirrung existiert um "redirect-on-write"-SnapShots - auch hier meint die eine Fraktion unsere NetApp-Technologie "Write Anywhere" und die andere ein SnapShot-Verfahren ala VSS und Vmware Snapshots.

just my 2 cents...

New Contributor

Ahm...

Hier (http://www.netapp.com/us/library/white-papers/wp_3002.html) steht im zweiten Absatz des Abstract: "WAFL uses a copy-on-write technique..."

Das hilft IMHO auch nicht gerade der Verwirrung entgegenzuwirken... ;-)

New Contributor

Ja, stimmt. Aber man  bedenke: Das Paper ist fast 20 Jahre alt und Dave Hitz hat damals auch noch in OS-Programmiererbahnen gedacht. Heute hat der Grossteil der Kollegen mit COW ein anderes Verstaendnis. Aber ist ja auch egal was nun "richtig" oder "falsch" ist, wichtig ist das wir hier auf mit der Sprache vorsichtig sein muessen, um nicht aneinander vorbei zu reden.