#
303975 |
|
11-Aug-2016 |
gjb |
Copy stable/11@r303970 to releng/11.0 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, and rename it to RC1.
Update __FreeBSD_version.
Use the quarterly branch for the default FreeBSD.conf pkg(8) repo and the dvd1.iso packages population.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
302408 |
|
08-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
275721 |
|
12-Dec-2014 |
marcel |
The size of the first level reference count table is given in terms of the number of clusters it occupies. It's not the number of entries in the table, as it is for the L1 cluster table.
For small images, the two are the same. With the unit tests based on small images, this change has therefore no effect on the unit test. For larger images (like the FreeBSD 10.1-RELEASE image), this gives a discrepancy that actually shows up when running "qemu-img check".
Bump the version number of mkimg.
While here, fix a white-space bug.
MFC after: 1 week
|
#
272086 |
|
24-Sep-2014 |
marcel |
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.
|
#
272072 |
|
24-Sep-2014 |
marcel |
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.
|
#
271965 |
|
22-Sep-2014 |
marcel |
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
|