|
|
| (46 intermediate revisions by 8 users not shown) |
| Line 1: |
Line 1: |
| =Specification= | | = Overview = |
|
| |
|
| The file format looks like this:
| | QED is an image format (like qcow2, vmdk, etc) that supports backing files and sparse images. |
|
| |
|
| +--------+----------+---------+---------+-----+
| | = Status = |
| | header | L1 table | extent0 | extent1 | ... |
| |
| +--------+----------+---------+---------+-----+
| |
|
| |
|
| ==Header==
| | * '''Base QED is in qemu.git''' since [http://git.qemu.org/qemu.git/commit/?id=75411d236d93d79d8052e0116c3eeebe23e2778b 2010-12-17] and will form part of QEMU 0.14. |
| Header {
| | * Merge plan for additional features: |
| uint32_t magic; /* COW2 */
| | ** Zero clusters [submitted]. |
|
| | ** Periodic dirty flag flush [submitted]. |
| uint32_t cluster_size; /* in bytes */
| | ** Image streaming [in preparation]. |
| uint32_t table_size; /* table size, in clusters */
| |
| uint32_t first_cluster; /* in clusters */
| |
|
| |
| uint64_t features; /* format feature bits */
| |
| uint64_t compat_features; /* compat feature bits */
| |
| uint64_t l1_table_offset; /* L1 table offset, in clusters */
| |
| uint64_t image_size; /* total image size, in clusters */
| |
|
| |
| /* if (features & QED_F_BACKING_FILE) */
| |
| uint32_t backing_file_offset; /* in bytes from start of header */
| |
| uint32_t backing_file_size; /* in bytes */
| |
|
| |
| /* if (compat_features & QED_CF_BACKING_FORMAT) */
| |
| uint32_t backing_fmt_offset; /* in bytes from start of header */
| |
| uint32_t backing_fmt_size; /* in bytes */
| |
| }
| |
|
| |
|
| ==Extent table== | | = Features = |
|
| |
|
| #define TABLE_NOFFSETS (table_size * cluster_size / sizeof(uint64_t))
| | * [[Features/QED/Specification|Open specification]] |
|
| | * Fully asynchronous I/O path |
| Table {
| | * Strong data integrity due to simple design |
| uint64_t offsets[TABLE_NOFFSETS];
| | * Backing files |
| }
| | ** Backing files may be smaller than the QED image |
| | * Sparse files |
| | ** Retains sparseness over non-sparse channels (e.g. HTTP) |
|
| |
|
| The extent tables are organized as follows:
| | = Current work = |
| | * [[Features/QED/OutstandingWork|Outstanding work]] |
|
| |
|
| +----------+
| | = Future Features = |
| | L1 table |
| | * [[Features/QED/Streaming|Streaming]] |
| +----------+
| | * [[Features/QED/OnlineDefrag|Online defragmentation]] |
| ,------' | '------.
| | * [[Features/QED/ParallelSubmission|Parallel submission]] |
| +----------+ | +----------+
| | * [[Features/QED/ScanAvoidance|Meta-data scan avoidance]] |
| | L2 table | ... | L2 table |
| |
| +----------+ +----------+
| |
| ,------' | '------.
| |
| +----------+ | +----------+
| |
| | Data | ... | Data |
| |
| +----------+ +----------+
| |
|
| |
|
| The table_size field allows tables to be multiples of the cluster size. For example, cluster_size=64 KB and table_size=4 results in 256 KB tables.
| | [[Category:Obsolete feature pages]] |
| | |
| =Operations=
| |
| | |
| ==Read==
| |
| # If L2 table is not present in L1, read from backing image.
| |
| # If data cluster is not present in L2, read from backing image.
| |
| # Otherwise read data from cluster.
| |
| | |
| ==Write==
| |
| # If L2 table is not present in L1, allocate new cluster and L2. Perform L2 and L1 link after writing data.
| |
| # If data cluster is not present in L2, allocate new cluster. Perform L1 link after writing data.
| |
| # Otherwise overwrite data cluster.
| |
| | |
| The L2 link '''should''' be made after the data is in place on storage. However, when no ordering is enforced the worst case scenario is an L2 link to an unwritten cluster.
| |
| | |
| The L1 link '''must''' be made after the L2 cluster is in place on storage. If the order is reversed then the L1 table may point to a bogus L2 table. (Is this a problem since clusters are allocated at the end of the file?)
| |
| | |
| ==Grow==
| |
| # If table_size * TABLE_NOFFSETS < new_image_size, fail -EOVERFLOW. The L1 table is not big enough.
| |
| # Write new image_size header field.
| |
| | |
| =Data integrity=
| |
| ==Write==
| |
| Writes that complete before a flush must be stable when the flush completes.
| |
| | |
| If storage is interrupted (e.g. power outage) then writes in progress may be lost, stable, or partially completed. The storage must not be otherwise corrupted or inaccessible after it is restarted.
| |
