d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
7ce14e216e
freebsd-skq/usr.bin/mkimg/qcow.c

370 lines
8.3 KiB
C
Raw Normal View History

Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
/*-
* Copyright (c) 2014 Marcel Moolenaar
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
#include <sys/types.h>
#include <sys/endian.h>
#include <sys/errno.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include "image.h"
#include "format.h"
#include "mkimg.h"
/* Default cluster sizes. */
#define QCOW1_CLSTR_LOG2SZ 12 /* 4KB */
#define QCOW2_CLSTR_LOG2SZ 16 /* 64KB */
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
/* Flag bits in cluster offsets */
#define QCOW_CLSTR_COMPRESSED (1ULL << 62)
#define QCOW_CLSTR_COPIED (1ULL << 63)
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
struct qcow_header {
uint32_t magic;
#define QCOW_MAGIC 0x514649fb
uint32_t version;
#define QCOW_VERSION_1 1
#define QCOW_VERSION_2 2
uint64_t path_offset;
uint32_t path_length;
uint32_t clstr_log2sz; /* v2 only */
uint64_t disk_size;
union {
struct {
uint8_t clstr_log2sz;
uint8_t l2_log2sz;
uint16_t _pad;
uint32_t encryption;
uint64_t l1_offset;
} v1;
struct {
uint32_t encryption;
uint32_t l1_entries;
uint64_t l1_offset;
uint64_t refcnt_offset;
uint32_t refcnt_entries;
uint32_t snapshot_count;
uint64_t snapshot_offset;
} v2;
} u;
};
static u_int clstr_log2sz;
static uint64_t
round_clstr(uint64_t ofs)
{
uint64_t clstrsz;
clstrsz = 1UL << clstr_log2sz;
return ((ofs + clstrsz - 1) & ~(clstrsz - 1));
}
static int
qcow_resize(lba_t imgsz, u_int version)
{
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
uint64_t imagesz;
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
switch (version) {
case QCOW_VERSION_1:
clstr_log2sz = QCOW1_CLSTR_LOG2SZ;
break;
case QCOW_VERSION_2:
clstr_log2sz = QCOW2_CLSTR_LOG2SZ;
break;
default:
return (EDOOFUS);
}
imagesz = round_clstr(imgsz * secsz);
if (verbose)
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
fprintf(stderr, "QCOW: image size = %ju, cluster size = %u\n",
(uintmax_t)imagesz, (u_int)(1U << clstr_log2sz));
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
return (image_set_size(imagesz / secsz));
}
static int
qcow1_resize(lba_t imgsz)
{
return (qcow_resize(imgsz, QCOW_VERSION_1));
}
static int
qcow2_resize(lba_t imgsz)
{
return (qcow_resize(imgsz, QCOW_VERSION_2));
}
static int
qcow_write(int fd, u_int version)
{
struct qcow_header *hdr;
Finish QCOW version 2 and stop making it conditional. We have a different ordering for the RC block(s) and L2 tables. This is expected to be a non-issue, because everything is found through file offsets in the corresponding RC table and L1 table. Files that grow organically have RC blocks and L2 tables scattered all over the place anyway. The reason for the difference is that mkimg needs to be able to write to a pipe. We can't seek forward and backward to fill in the bits in non-sequential order.
2014-09-24 22:45:03 +00:00
uint64_t *l1tbl, *l2tbl, *rctbl;
uint16_t *rcblk;
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
uint64_t clstr_imgsz, clstr_l2tbls, clstr_l1tblsz;
uint64_t clstr_rcblks, clstr_rctblsz;
uint64_t n, imagesz, nclstrs, ofs, ofsflags;
lba_t blk, blkofs, blk_imgsz;
u_int l1clno, l2clno, rcclno;
u_int blk_clstrsz;
u_int clstrsz, l1idx, l2idx;
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
int error;
if (clstr_log2sz == 0)
return (EDOOFUS);
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
clstrsz = 1U << clstr_log2sz;
blk_clstrsz = clstrsz / secsz;
blk_imgsz = image_get_size();
imagesz = blk_imgsz * secsz;
clstr_imgsz = imagesz >> clstr_log2sz;
clstr_l2tbls = round_clstr(clstr_imgsz * 8) >> clstr_log2sz;
clstr_l1tblsz = round_clstr(clstr_l2tbls * 8) >> clstr_log2sz;
nclstrs = clstr_imgsz + clstr_l2tbls + clstr_l1tblsz + 1;
clstr_rcblks = clstr_rctblsz = 0;
do {
n = clstr_rcblks + clstr_rctblsz;
clstr_rcblks = round_clstr((nclstrs + n) * 2) >> clstr_log2sz;
clstr_rctblsz = round_clstr(clstr_rcblks * 8) >> clstr_log2sz;
} while (n < (clstr_rcblks + clstr_rctblsz));
/*
* We got all the sizes in clusters. Start the layout.
* 0 - header
* 1 - L1 table
* 2 - RC table (v2 only)
Finish QCOW version 2 and stop making it conditional. We have a different ordering for the RC block(s) and L2 tables. This is expected to be a non-issue, because everything is found through file offsets in the corresponding RC table and L1 table. Files that grow organically have RC blocks and L2 tables scattered all over the place anyway. The reason for the difference is that mkimg needs to be able to write to a pipe. We can't seek forward and backward to fill in the bits in non-sequential order.
2014-09-24 22:45:03 +00:00
* 3 - L2 tables
* 4 - RC block (v2 only)
* 5 - data
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
*/
l1clno = 1;
rcclno = 0;
Finish QCOW version 2 and stop making it conditional. We have a different ordering for the RC block(s) and L2 tables. This is expected to be a non-issue, because everything is found through file offsets in the corresponding RC table and L1 table. Files that grow organically have RC blocks and L2 tables scattered all over the place anyway. The reason for the difference is that mkimg needs to be able to write to a pipe. We can't seek forward and backward to fill in the bits in non-sequential order.
2014-09-24 22:45:03 +00:00
rctbl = l2tbl = l1tbl = NULL;
rcblk = NULL;
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
hdr = calloc(1, clstrsz);
if (hdr == NULL)
return (errno);
be32enc(&hdr->magic, QCOW_MAGIC);
be32enc(&hdr->version, version);
be64enc(&hdr->disk_size, imagesz);
switch (version) {
case QCOW_VERSION_1:
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
ofsflags = 0;
l2clno = l1clno + clstr_l1tblsz;
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
hdr->u.v1.clstr_log2sz = clstr_log2sz;
hdr->u.v1.l2_log2sz = clstr_log2sz - 3;
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
be64enc(&hdr->u.v1.l1_offset, clstrsz * l1clno);
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
break;
case QCOW_VERSION_2:
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
ofsflags = QCOW_CLSTR_COPIED;
rcclno = l1clno + clstr_l1tblsz;
Finish QCOW version 2 and stop making it conditional. We have a different ordering for the RC block(s) and L2 tables. This is expected to be a non-issue, because everything is found through file offsets in the corresponding RC table and L1 table. Files that grow organically have RC blocks and L2 tables scattered all over the place anyway. The reason for the difference is that mkimg needs to be able to write to a pipe. We can't seek forward and backward to fill in the bits in non-sequential order.
2014-09-24 22:45:03 +00:00
l2clno = rcclno + clstr_rctblsz;
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
be32enc(&hdr->clstr_log2sz, clstr_log2sz);
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
be32enc(&hdr->u.v2.l1_entries, clstr_l2tbls);
be64enc(&hdr->u.v2.l1_offset, clstrsz * l1clno);
be64enc(&hdr->u.v2.refcnt_offset, clstrsz * rcclno);
be32enc(&hdr->u.v2.refcnt_entries, clstr_rcblks);
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
break;
default:
return (EDOOFUS);
}
Finish QCOW version 2 and stop making it conditional. We have a different ordering for the RC block(s) and L2 tables. This is expected to be a non-issue, because everything is found through file offsets in the corresponding RC table and L1 table. Files that grow organically have RC blocks and L2 tables scattered all over the place anyway. The reason for the difference is that mkimg needs to be able to write to a pipe. We can't seek forward and backward to fill in the bits in non-sequential order.
2014-09-24 22:45:03 +00:00
if (sparse_write(fd, hdr, clstrsz) < 0) {
error = errno;
goto out;
}
free(hdr);
hdr = NULL;
ofs = clstrsz * l2clno;
nclstrs = 1 + clstr_l1tblsz + clstr_rctblsz;
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
l1tbl = calloc(1, clstrsz * clstr_l1tblsz);
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
if (l1tbl == NULL) {
error = ENOMEM;
goto out;
}
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
for (n = 0; n < clstr_imgsz; n++) {
blk = n * blk_clstrsz;
if (image_data(blk, blk_clstrsz)) {
Finish QCOW version 2 and stop making it conditional. We have a different ordering for the RC block(s) and L2 tables. This is expected to be a non-issue, because everything is found through file offsets in the corresponding RC table and L1 table. Files that grow organically have RC blocks and L2 tables scattered all over the place anyway. The reason for the difference is that mkimg needs to be able to write to a pipe. We can't seek forward and backward to fill in the bits in non-sequential order.
2014-09-24 22:45:03 +00:00
nclstrs++;
l1idx = n >> (clstr_log2sz - 3);
if (l1tbl[l1idx] == 0) {
be64enc(l1tbl + l1idx, ofs + ofsflags);
ofs += clstrsz;
nclstrs++;
}
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
}
}
Finish QCOW version 2 and stop making it conditional. We have a different ordering for the RC block(s) and L2 tables. This is expected to be a non-issue, because everything is found through file offsets in the corresponding RC table and L1 table. Files that grow organically have RC blocks and L2 tables scattered all over the place anyway. The reason for the difference is that mkimg needs to be able to write to a pipe. We can't seek forward and backward to fill in the bits in non-sequential order.
2014-09-24 22:45:03 +00:00
if (sparse_write(fd, l1tbl, clstrsz * clstr_l1tblsz) < 0) {
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
error = errno;
goto out;
Finish QCOW version 2 and stop making it conditional. We have a different ordering for the RC block(s) and L2 tables. This is expected to be a non-issue, because everything is found through file offsets in the corresponding RC table and L1 table. Files that grow organically have RC blocks and L2 tables scattered all over the place anyway. The reason for the difference is that mkimg needs to be able to write to a pipe. We can't seek forward and backward to fill in the bits in non-sequential order.
2014-09-24 22:45:03 +00:00
}
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
Finish QCOW version 2 and stop making it conditional. We have a different ordering for the RC block(s) and L2 tables. This is expected to be a non-issue, because everything is found through file offsets in the corresponding RC table and L1 table. Files that grow organically have RC blocks and L2 tables scattered all over the place anyway. The reason for the difference is that mkimg needs to be able to write to a pipe. We can't seek forward and backward to fill in the bits in non-sequential order.
2014-09-24 22:45:03 +00:00
clstr_rcblks = 0;
do {
n = clstr_rcblks;
clstr_rcblks = round_clstr((nclstrs + n) * 2) >> clstr_log2sz;
} while (n < clstr_rcblks);
if (rcclno > 0) {
rctbl = calloc(1, clstrsz * clstr_rctblsz);
if (rctbl == NULL) {
error = ENOMEM;
goto out;
}
for (n = 0; n < clstr_rcblks; n++) {
be64enc(rctbl + n, ofs);
ofs += clstrsz;
nclstrs++;
}
if (sparse_write(fd, rctbl, clstrsz * clstr_rctblsz) < 0) {
error = errno;
goto out;
}
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
free(rctbl);
rctbl = NULL;
}
l2tbl = malloc(clstrsz);
if (l2tbl == NULL) {
error = ENOMEM;
goto out;
}
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
for (l1idx = 0; l1idx < clstr_l2tbls; l1idx++) {
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
if (l1tbl[l1idx] == 0)
continue;
memset(l2tbl, 0, clstrsz);
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
blkofs = (lba_t)l1idx * blk_clstrsz * (clstrsz >> 3);
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
for (l2idx = 0; l2idx < (clstrsz >> 3); l2idx++) {
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
blk = blkofs + (lba_t)l2idx * blk_clstrsz;
if (blk >= blk_imgsz)
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
break;
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
if (image_data(blk, blk_clstrsz)) {
be64enc(l2tbl + l2idx, ofs + ofsflags);
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
ofs += clstrsz;
}
}
if (sparse_write(fd, l2tbl, clstrsz) < 0) {
error = errno;
goto out;
}
}
free(l2tbl);
l2tbl = NULL;
free(l1tbl);
l1tbl = NULL;
Finish QCOW version 2 and stop making it conditional. We have a different ordering for the RC block(s) and L2 tables. This is expected to be a non-issue, because everything is found through file offsets in the corresponding RC table and L1 table. Files that grow organically have RC blocks and L2 tables scattered all over the place anyway. The reason for the difference is that mkimg needs to be able to write to a pipe. We can't seek forward and backward to fill in the bits in non-sequential order.
2014-09-24 22:45:03 +00:00
if (rcclno > 0) {
rcblk = calloc(1, clstrsz * clstr_rcblks);
if (rcblk == NULL) {
error = ENOMEM;
goto out;
}
for (n = 0; n < nclstrs; n++)
be16enc(rcblk + n, 1);
if (sparse_write(fd, rcblk, clstrsz * clstr_rcblks) < 0) {
error = errno;
goto out;
}
free(rcblk);
rcblk = NULL;
}
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
error = 0;
Fix the creation of the L2 cluster table for version 1. The blkofs variable was assigned the image offset in bytes and not in blocks (i.e. sectors). This had image_data() return FALSE, which meant that we didn't assign a cluster when we needed and also meant that we didn't write parts of the L2 table when we should have. The result being that the actual data clusters were written at the wrong offset. Improve support for QCOW version 2. We're having the right layout and even know how many refcnt blocks we need. All we need to do is populate the refcnt blocks for every cluster we write and allocate a cluster when we need a new refcnt block. The allocation part is tricky in that it'll interleave with the assignment of clusters to L2 tables and data. Since version 2 is not quite done, keep it compiled out for now.
2014-09-24 15:14:01 +00:00
for (n = 0; n < clstr_imgsz; n++) {
blk = n * blk_clstrsz;
if (image_data(blk, blk_clstrsz)) {
error = image_copyout_region(fd, blk, blk_clstrsz);
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
if (error)
break;
}
}
if (!error)
error = image_copyout_done(fd);
out:
Finish QCOW version 2 and stop making it conditional. We have a different ordering for the RC block(s) and L2 tables. This is expected to be a non-issue, because everything is found through file offsets in the corresponding RC table and L1 table. Files that grow organically have RC blocks and L2 tables scattered all over the place anyway. The reason for the difference is that mkimg needs to be able to write to a pipe. We can't seek forward and backward to fill in the bits in non-sequential order.
2014-09-24 22:45:03 +00:00
if (rcblk != NULL)
free(rcblk);
Add support for QCOW version 1. Version 2 is partially implemented. And because of that, it's entirely disabled for now. Both versions are similar enough that a single header definition works for both of them. The only "diverting" side-effect is that the union of the two is larger than the official V1 header. What this means for our V1 support is that we can't put the L1 table adjacent to the V1 header (i.e. at offset 0x30 in the file), unless we revert to hackery and klugery. Let's not. Instead, we align the L1 table at the cluster boundary. This is in line with the V2 layout and perfectly ok for V1 anyway (ok -- as far as I've seen so far). Due to the alignment, our V1 image seems to be 1 cluster larger than the V1 image created by qemu-img (on average). Compression of the clusters is not supported at this time. MFC after: 2 months
2014-09-22 15:05:28 +00:00
if (l2tbl != NULL)
free(l2tbl);
if (rctbl != NULL)
free(rctbl);
if (l1tbl != NULL)
free(l1tbl);
if (hdr != NULL)
free(hdr);
return (error);
}
static int
qcow1_write(int fd)
{
return (qcow_write(fd, QCOW_VERSION_1));
}
static int
qcow2_write(int fd)
{
return (qcow_write(fd, QCOW_VERSION_2));
}
static struct mkimg_format qcow1_format = {
.name = "qcow",
.description = "QEMU Copy-On-Write, version 1",
.resize = qcow1_resize,
.write = qcow1_write,
};
FORMAT_DEFINE(qcow1_format);
static struct mkimg_format qcow2_format = {
.name = "qcow2",
.description = "QEMU Copy-On-Write, version 2",
.resize = qcow2_resize,
.write = qcow2_write,
};
FORMAT_DEFINE(qcow2_format);
Reference in New Issue Copy Permalink