Copy On Write ( COW )

Immer wieder werde ich gefragt, was denn nun eigentlich COW ist und wie ZFS Datenblöcke schreibt.
In diesem Zusammenhang werde ich auch oft mit anderen, sogeannten COW Verfahren konfrontiert, wie beispielsweise der Beschreibung von IBM, die diesen Begriff auch fuer ihr Verfahren zur Erstellung von Snapshots verwendet. Allerdings hat deren Verfahren mit COW herzlich wenig zu tun, und die Definition von COW wird verballhornt.

Copy-on-write, Snapshots und andere Verfahren

Copy-on-write bezeichnet zunaechst einmal ein Optimierungsverfahren/Algorithmus, bei denen Prozesse auf ein und dieselben Daten einer Speicherseite zugreifen koennen, so dass diese Daten nicht mehrfach gespeichert werden muessen. Die Adressbereiche der Prozesse verweisen dann auf die gleiche Speicherseite. Die Daten liegen im Speicher nur read-only vor.

Erst wenn diese Daten manipuliert werden sollen, wird eine Kopie, und dies auch nur teilweise erstellt, so dass die Aenderungen fuer die anderen Prozess nicht sichtbar sind. Vorteil dieses Verfahrens ist, dass solange Daten nicht modifiziert werden, keine Kopie erstellt werden muss. Deswegen heisst es, copy-on-write (COW ).

Fuer Dateisysteme heisst Copy-on-write, dass geaenderte Datenbloecke nicht ueberschrieben werden.
Sie werden stattdessen an einen freien Platz geschrieben und die Metadatenbloecke werden anschliessend angepasst und verweisen nun auf den neuen Block. Die originalen Bloecke bleiben erhalten, so dass diese nun den Snapshot bilden koennen.
Damit unterscheidet sich ZFS von herkoemmlichen Dateisystemen, die mit dem Verfahren read-modify-write arbeiten. In diesem Falle werden die Datenbloecke in einer sog. atomaren Operation eingelesen, veraendert und anschliessend überschrieben.
Sollte bei diesem Schreibvorgang die Daten korrumpiert worden sein, so gibt es kein Zurueck, da die originalen Daten ueberschrieben wurden.

COW ist keine Erfindung von Netapp oder IBM oder Sun mit ZFS, sondern diesen Algorithmus gibt es schon lange in Unix Systemen.

Literatur allgemein zu COW:
http://de.wikipedia.org/wiki/Copy-On-Write

COW wird hauptsaechlich in Virtual-Memory-Subsystemen verwendet. Das heisst, ein Prozess erstellt eine Kopie von sich selbst, und die zu aendernden Speicherseiten der Kopie oder des Prozesses selbst werden markiert als „copy-on-write“.
Veraendert ein Prozess die Daten im Speicher, sorgt das Betriebssystem vorher dafuer, dass eine Kopie der Seiten erstellt wird, die dann geaendert wird. Die Aenderungen bleiben fuer die anderen Prozesse unsichtbar.

Literatur: COW im VM subsystem, Algorithmus:

http://courses.cs.vt.edu/~cs3204/spring2009/butta/local/lectures/lecture-18.pdf
http://tkhanson.net/virtual_memory.pdf
https://www.systems.inf.ethz.ch/education/past-courses/fs10/operating-systems-and-networks/slides/chapter17-6up.pdf

COW Verfahren wird auch noch zu anderen Zwecken eingesetzt, beispielsweise in Virtualisierungssoftware oder Emulatoren wie QEMU, so dass VMs auf das gleiche VM Disk Image zu greifen koennen, was den Speicherbedarf reduziert.

ZFS nutzt das copy-on-write, transaktionale Objekt Modell.
Bloecke werden niemals ueberschrieben, sondern es wird stattdessen ein neuer Block allokiert, die Daten werden im neuen Datenblock modifiziert, dann werden die Metadatenbloecke auf den neuen Block referenziert und wenn dies erfolgreich abgeschlossen werden konnte, erst dann ist die Transaktion beendet.
Damit der Overhead reduziert wird, werden mehrere Aenderungen zu Transaktionsgruppen zusammengefasst und bei synchronen Schreibvorgaengen wird der intent log eingesetzt.

Da die originalen, veralteten Bloecke nicht ueberschrieben werden, koennen diese fuer Snapshots genutzt werden. Das ist auch der Grund, warum die Snapshots in ZFS sehr schnell erstellt werden, da die Daten ja bereits vorhanden sind, – sie sind eben im ZFS immanent enthalten.
Ausserdem verbrauchen sie keinen zusaetzlichen Speicherplatz, da nur geaenderte Daten neu gespeichert werden. Nicht modifizierte Daten werden vom Dateisystem und den Snapshots gemeinsam genutzt.

Clones, also schreibbare Snapshots, bilden ein eigenes unabhaengiges Dateisystem, das sich eine Sammlung von Bloecken mit den Snapshots teilt.
Wenn nun eine Aenderung im Clone stattfindet, dann werden neue Datenbloecke erstellt, die diese Aenderungen enthalten, aber die ungeaenderten Datenbloecke werden weiterhin miteinander geteilt, unabhaengig davon wie viele Clones bestehen moegen.

Literatur zu COW und ZFS:
http://all-unix.blogspot.com/2007/03/zfs-cow-and-relate-features.html

IBM hat Patente die auf COW aufsetzen, ebenso wie NetApp ( siehe unten die Literaturhinweise).
Das heisst, sie alle nutzen den COW Algorithmus, verwenden aber eigene Methoden, die sie dann patentieren lassen.

So mag NetApp der Meinung sein Sun haette mit ZFS ehemals ihr WAFL Patent penetriert, aber das hat mit COW erstmal nichts zu tun, da dies ein Algorithmus ist, und kein Patent.
Dass das Optimierungsverfahren schon frueher fuer Filesysteme genutzt wurde, sieht man auch an Joerg Schillings Diplomarbeit zu WoFS, also vor WAFL und ZFS.

IBM beschreibt den COW Vorgang fuer Snapshots auf dieser Seite ganz anders:
http://www.ibm.com/developerworks/tivoli/library/t-snaptsm1/index.html
Es wird deutlich, dass die hier beschriebene Verfahren mit COW im eigentlichen Sinne nichts zu tun haben.

Dort steht:
A snapshot of a storage volume is created using the pre-designated space for the snapshot. When the snapshot is first created, only the meta-data about where original data is stored is copied. No physical copy of the data is done at the time the snapshot is created. Therefore, the creation of the snapshot is almost instantaneous. The snapshot copy then tracks the changing blocks on the original volume as writes to the original volume are performed. The original data that is being written to is copied into the designated storage pool that is set aside for the snapshot before original data is overwritten, hence the name „copy-on-write“.

Das beschreibt lediglich, wie IBM Snapshots erzeugt.
Naemlich:
erst werden die Bloecke in einen designierten Storage Pool kopiert ( Der originale Datenblock wird eingelesen und in ein anderes Volume kopiert ), bevor dann die originalen Daten veraendert werden ( Der originale Datenblock wird veraendert und dann an seine usprüngliche Stelle zurueckgeschreiben, so dass dieser nun ueberschrieben ist).

Der Begriff „copy-on-write“ wird hier nicht richtig verwendet. So wie IBM verfaehrt, muesste der Vorgang heissen: first-copy-then-overwrite.

Das oben beschreibene Verfahren von IBM unterscheidet sich grundlegend von der Art und Weise wie ZFS Datenblöcke per COW modifiziert.
1. ZFS schreibt nicht eine Kopie des originalen Datenblocks in einen designierten Pool.
2. ZFS überschreibt keine Datenblöcke.
3. ZFS liest einen Datenblock ein, veraendert diesen und schriebt diesen dann an eine freie Stelle im Pool.
4. Der originale Block, der noch vorhanden ist, stellt den Snapshot dar, sofern dieser erzeugt wurde.

Und weiter heisst es bei IBM:
Before a write is allowed to a block, copy-on-write moves the original data block to the snapshot storage. This keeps the snapshot data consistent with the exact time the snapshot was taken. Read requests to the snapshot volume of the unchanged data blocks are redirected to the original volume, while read requests to data blocks that have been changed are directed to the „copied“ blocks in the snapshot. Snapshot contains the meta-data that describes the data blocks that have changed since the snapshot was first created. Note that original data blocks are copied only once into the snapshot storage when the first write request is received.

Das beschriebene Verfahren bezieht sich wiederum auf das Handling der Bloecke im Storage, aber nicht die Art und Weise wie damit im Memory und VM Subsystemen umgegangen wird.
COW meint nicht, dass ein Datenblock erst an eine andere Stelle kopiert wird, das Original eingelesen, dann veraendert und schliesslich das urprüngliche Original ueberschrieben wird.
COW meint, dass ein Datenblock eingelesen, veraendert und dann an andere Stelle geschrieben werden, so dass ein neuer Block entsteht, und der Originale erhalten bleibt.

Das sind also zwei voellig unterschedliche Vorgehensweisen.

Weiter in dem IBM Artikel, wird dann noch ein weiteres Verfahren beschrieben wie IBM mit Snapshots umgeht:

Redirect-on-write
This method is quite similar to copy-on-write, without the double write penalty, and it offers storage space and performance efficient snapshots.
New writes to the original volume are redirected to another location set aside for snapshot. The advantage of redirecting the write is that only one write takes place, whereas with copy-on-write, two writes occur (one to copy original data onto the storage space, the other to copy changed data).

Es wird mit dem beschriebenen Verfahren, im Gegenstaz zum Vorherigen, keine Kopie des originalen Blocks im Snapshot Bereich erzeugt ( 1. write Operation ) und der originale Block dann ueberschrieben ( 2. write Operation ), sondern der bereits vorhandene Block im Snapshot Bereich wird direkt ueberschrieben ( 1. write Operation ). Auf diese Weise befindet sich nun der originale Block als Snapshot im originalen Volume, und die geaenderten Daten in dem Snapshot Volume. Als Folge davon muessen Datenbloecke im Falle des Loeschen von Snapshots vom Snapshotbereich zurueck kopiert werden in den originalen Bereich.

However, with redirect-on-write, the original copy contains the point-in-time data, that is, snapshot, and the changed data reside on the snapshot storage. When a snapshot is deleted, the data from the snapshot storage must be reconciled back into the original volume. Furthermore, as multiple snapshots are created, access to the original data, tracking of the data in snapshots and original volume, and reconciliation upon snapshot deletion is further complicated . The snapshot relies on the original copy of the data and the original data set can quickly become fragmented.

Wenn Snapshots mit ZFS geloescht werden, so geschieht das einfach damit, dass die Datenblöcke des Snapshots „gefreed“ werden.
Ein Kopieren von einem designierten Snapshot-Bereich zurueck in den originalen Pool ist nicht erforderlich.
Daher sind die Operationen, die mit ZFS benoetigt werden auch wesentlich geringer.

Literaturhinweise:
netapp snapshot patente:

http://www.patentgenius.com/patent/7467167.html
http://www.freepatentsonline.com/7467167.html
http://www.freepatentsonline.com/5819292.html

netapp WAFL patent mit COW:

http://www.freepatentsonline.com/6289356.html
http://www.freepatentsonline.com/5963962.html

Joerg Schillings master thesis fuer WORM file system basierend auf COW:

http://cdrecord.berlios.de/private/WoFS.pdf

IBM patent fuer COW im VM subsystem:

http://www.freepatentsonline.com/4742450.html
http://www.freepatentsonline.com/4742447.html

COW im VM subsystem, algorithmus:

http://courses.cs.vt.edu/~cs3204/spring2009/butta/local/lectures/lecture-18.pdf
http://tkhanson.net/virtual_memory.pdf
https://www.systems.inf.ethz.ch/education/past-courses/fs10/operating-systems-and-networks/slides/chapter17-6up.pdf

COW und ZFS:

http://all-unix.blogspot.com/2007/03/zfs-cow-and-relate-features.html

some things about ZFS

Recently I stumbled across this blog-entry. This guy, Marcelo Leal, wrote a ZFS internals book and blogged his thoughts about ZFS.

But his thoughts/ opinions are misleading.

1. he says, RAIDZ performs poorly and he gives the advice not to use RAIDZ but mirrors.
QUOTE
It’s not useless, you can use it at home, even for backups in a datacenter solution, but you need to have a robust infrastructure to deal with long resilvers and really poor restore procedures. Everything is a whole stripe solves one problem and creates a bottleneck for performance and a nightmare for the resilver process (ZFS needs to traverse the whole filesystem to resiver a disk). If you care, i can give you an advice: if you want to use it, three discs in a set is the maximum you can obtain for it.
QUOTE END

Pardon, but this is complete nonsens.
The bad performance of his „datacenter solution“ is not root caused by ZFS but by his very cheap and slow SATA drives.
These drives are for consumer purposes but not for real datacenters.
The duration of resilvering depends on the performance of disks and size of the filesystem. ( 2 TB SATA disk with 7200 rpms ). An fsck also takes its time. An sync executed by a volume manger reads block by block and sync block by block.
But to speed up, use faster disks for enterprise purposes instead of consumer disks.

ZFS consumes some more ressources than other filesystems, that is true. Applications consumes ressources, Volume Managers, too. So what?
Usually todays boxes have enough ressources to handle this, so that is not the point. In return ZFs provides better reliability.

Secondly, you do not need to buy any raid controllers. Other vendors, like the one I recently met, boosts the performance by the numbers of disks and having RAID Controllers on every single tray!!! Ops, this might boost the performance since the calculation of raid algorithms are distributed over the trays, but every singel raid controller is a single point of failure.

His advice to use a MAXIMUM of three disks is nonsens. You cannot create a RAIDZ with two discs 😉 so what’s the minimum?
Additionally, take in consideration that the performance is much slower using only 3 disks than using 6 or 7 disks. The more disks, the better the performance, untill the break-even, when too many disks flatten the perfomance.

Then he forgot to mention that RAIDZ doesn’t work a usual RAID5.
ZFS uses dynamic block sizes, so ZFS calculates how many disks are used and the size of the blocks to store the data redundantly. Take a look at my raid-z document and you see an image how ZFS allocates blocks and what is the difference of RAIDZ to common RAID level.
So RAIDZ consumes less disk space than other RAID5 sets and, of course, mirroring.
If you want a detailed explanation why mirroring performs in some cases better than RAIDZ read this article „WHEN TO (AND NOT TO) USE RAID-Z“.

2. He claims about the lack of L2ARC redundancy and performance.
QUOTE
The data is on disk, we can access it from there in the case of loosing the SSD data. No, no, we can not get it from there! ZFS loves cheap discs, our discs is 7200 SATA discs… they do know how to store data, but do not know how to read it. These 7200 SATA drives should have a banner saying: Pay to write it and pray for read it.
QUOTE END

To compensate the bad performance of SATA disks the system needs cache ( usually nvram ) to read and write. This is why people now uses seperate devices like SSDs.

And what is he talking about?
Read performance or write performance ?

If data is written on SSD as seperate ZIL devices the data is written on stable storage! Period.

If data is read, than the data has been already written to stable storage and is now cached, whereever that is ( RAM or SSD, disk ).
If you uses slow disks, you have slow performance unless you read from faster devices like RAM or SSD.

It is true, the L2Arc needs a warm up, since the L2Arc ist the second-level cache which means:
1. the data is cached in ARC, and when data is evicted by ZFS it is
2. written to L2ARC, for instance on SSD. So there must be read requesst and somewhat a „load“ to fill up the L2ARC.

How the ARC and L2ARC works is described in my L2ARC document.
If you like to read more about seperate cache devices, take my advice and read this written by experts.

BTW, using SATA discs with 7200 rpms is not a good solution for speed up the performance, either for read nor for write requests. It is just 7200 rpm nstead of 15000 rpms.

My advice, do not buy cheap, buy some faster, realiable disks , use a good storage architecture, and everythings speeds up. 🙂

Third, he talks about fragmentation caused by incremental snapshots in ZFS.
This is not in particular a problem of ZFS.
Every filesystems suffer fragmentation over time.

And 4th about some another „myths“.
If you won’t read about myths, read the ZFS-Best Practices Guide, written by ZFS experts.

Brosug

Vergangenen Monat am 17. Maerz, war ich wieder bei der Brosug eingeladen worden, einen Vortrag zu halten.

Wir trafen uns am Weigandufer im Buero 2.0 in Berlin-Neukoelln. Ich hielt meinen Vortrag ueber ZFS – Readzilla und Logzilla ( ZIL und ARC ), den ich bereits bei der Partner Veranstaltung der Cadac – Talk about IT – und bei meinem Sun Breakfast hielt. Meine Presentationen habe ich fuer diesen Anlass ein klein wenig ueberarbeitet und verfeinert.

Wir waren eine kleine, aber sehr feine Runde. Die Teilnehmer – und dafuer moechte ich meinen Dank aussprechen – waren sehr am Thema interessiert und hatten viele interessante Fragen aus ihrer Praxis, so dass wir auch viel diskutierten.

Hat Spass gemacht.

claudia

ZFS Readzilla and Logzilla: ZFS ARC & L2ARC and the ZIL & slog

Yesterday I held a presentation about ZFS Readzilla and Logzilla, ZFS ARC and Zil and how it works at the CADAC Day.
You can use readzilla and Logzilla devices in our Sun Storage Unified Storage Systems aka Openstorage to boost the read and write performance.
What’s all about it you can read in my presentations ZFS_arc available in english as well as in german:
ZFS ARC english
ZFS_ARC german

claudia

RAID-Z – What is it and what its benefit ??

Moin Moin folks,

– english Version below in orange – 

oft werde ich von meinen Kunden gefragt: "Was ist eigentlich RAIDZ und wie kann es Redundanz und die Integritaet der Daten garantieren?

Und ich beginne einen Email zu verfassen und beschreibe die Funktionalitaeten von ZFS ( self-healing, checksumming), ich erzaehle von zpools, Spiegeln des zpools und Einrichten von RAIDZ.

Und ich verweise auf die zahlreichen Blog Einträge auf blogs.sun.com.

Oh – sagt der Kunde, das ist ja alles in englisch, gibt es denn da nichts in deutsch.

Nein, musste ich bisher sagen.. bisher.

Nun habe ich mich mal hingesetzt und ein Dokument in deutsch verfasst: 

English Version 

often, I am asked by my german customers, what is RAID-Z and how does it guarantee data integrity and redundancy and I start to write an email describing the features of ZFS: self healing, checksumming, and this in combination with mirrored zpools or RAID-Z zpools.
And I refer to the links of blogs.sun.com.
Uh – the customers moan, – but this is in english! Aren’t there any documents in german?

No, until now

Here is my whitepaper about traditional RAID-Systems ( for comparision and for general information ) and RAID-Z and it’s benefits against RAID5.
If you have comments, suggestions etc. please send me an email.

Have a nice day
Claudia

https://claudidays.files.wordpress.com/2011/04/raid-z.pdf