From: Jeff Cody <jcody@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: kwolf@redhat.com, famz@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 2/9] block: vhdx - add header update capability.
Date: Thu, 1 Aug 2013 10:09:25 -0400 [thread overview]
Message-ID: <20130801140925.GI19714@localhost.localdomain> (raw)
In-Reply-To: <20130801134441.GD2387@stefanha-thinkpad.redhat.com>
On Thu, Aug 01, 2013 at 03:44:41PM +0200, Stefan Hajnoczi wrote:
> On Wed, Jul 31, 2013 at 11:23:47PM -0400, Jeff Cody wrote:
> > @@ -212,6 +242,24 @@ bool vhdx_checksum_is_valid(uint8_t *buf, size_t size, int crc_offset)
> >
> >
> > /*
> > + * This generates a UUID that is compliant with the MS GUIDs used
> > + * in the VHDX spec (and elsewhere).
> > + *
> > + * We can do this with uuid_generate if uuid.h is present,
> > + * however not all systems have uuid and the generation is
> > + * pretty straightforward for the DCE + random usage case
>
> The talk of uuid.h not being available confuses me. The code has no
> #ifdef and we do not define uuid_generate() ourselves.
>
> Is this an outdated comment?
Yes, the comment is outdated from when I had my own UUID generation in
the patch - I missed removing the comment.
>
> > +/* Update the VHDX headers
> > + *
> > + * This follows the VHDX spec procedures for header updates.
> > + *
> > + * - non-current header is updated with largest sequence number
> > + */
> > +static int vhdx_update_header(BlockDriverState *bs, BDRVVHDXState *s, bool rw)
>
> "rw" should be named "generate_file_write_guid". If you call
> vhdx_update_header() again later you do not need to update FileWriteGuid
> again according to the spec. There's probably no harm in doing so but
> the spec explicitly says "If this is the first header update within the
> session, use a new value for the FileWriteGuid".
>
> This means that future calls to vhdx_update_header() in the same session
> should set "generate_file_write_guid" to false. Therefore "rw" is not
> the right name.
>
Yes, it is a bit misnamed. I'll change the name. However, redundant
generation is protected against with via vhdx_user_visible_write(),
introduced in patch 6, which is the only placed that calls it with rw
= true (soon to be generate_file_write_guid = true).
> > +{
> > + int ret = 0;
> > + int hdr_idx = 0;
> > + uint64_t header_offset = VHDX_HEADER1_OFFSET;
> > +
> > + VHDXHeader *active_header;
> > + VHDXHeader *inactive_header;
> > + VHDXHeader header_le;
> > + uint8_t *buffer;
> > +
> > + /* operate on the non-current header */
> > + if (s->curr_header == 0) {
> > + hdr_idx = 1;
> > + header_offset = VHDX_HEADER2_OFFSET;
> > + }
> > +
> > + active_header = s->headers[s->curr_header];
> > + inactive_header = s->headers[hdr_idx];
> > +
> > + inactive_header->sequence_number = active_header->sequence_number + 1;
> > +
> > + /* a new file guid must be generate before any file write, including
>
> s/generate/generated/
>
Thanks
> > + * headers */
> > + memcpy(&inactive_header->file_write_guid, &s->session_guid,
> > + sizeof(MSGUID));
> > +
> > + /* a new data guid only needs to be generate before any guest-visible
> > + * writes, so update it if the image is opened r/w. */
> > + if (rw) {
> > + vhdx_guid_generate(&inactive_header->data_write_guid);
> > + }
> > +
> > + /* the header checksum is not over just the packed size of VHDXHeader,
> > + * but rather over the entire 'reserved' range for the header, which is
> > + * 4KB (VHDX_HEADER_SIZE). */
> > +
> > + buffer = qemu_blockalign(bs, VHDX_HEADER_SIZE);
> > + /* we can't assume the extra reserved bytes are 0 */
> > + ret = bdrv_pread(bs->file, header_offset, buffer, VHDX_HEADER_SIZE);
> > + if (ret < 0) {
> > + goto exit;
> > + }
> > + /* overwrite the actual VHDXHeader portion */
> > + memcpy(buffer, inactive_header, sizeof(VHDXHeader));
> > + inactive_header->checksum = vhdx_update_checksum(buffer,
> > + VHDX_HEADER_SIZE, 4);
> > + vhdx_header_le_export(inactive_header, &header_le);
> > + bdrv_pwrite_sync(bs->file, header_offset, &header_le, sizeof(VHDXHeader));
>
> This function can fail and it's a good indicator that future I/Os will
> also be in trouble. Please propagate the error return.
>
You are right, that was unintentional.
> > @@ -801,8 +955,7 @@ static int vhdx_open(BlockDriverState *bs, QDict *options, int flags)
> > }
> >
> > if (flags & BDRV_O_RDWR) {
> > - ret = -ENOTSUP;
> > - goto fail;
> > + vhdx_update_headers(bs, s, false);
>
> Error handling is missing. At this point it looks like we cannot write
> to the file. Propagating the error seems reasonable.
OK, I move the above change into when the write support is actually in
place.
next prev parent reply other threads:[~2013-08-02 3:01 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-01 3:23 [Qemu-devel] [PATCH v2 0/9] VHDX log replay and write support Jeff Cody
2013-08-01 3:23 ` [Qemu-devel] [PATCH v2 1/9] block: vhdx - minor comments and typo correction Jeff Cody
2013-08-01 3:23 ` [Qemu-devel] [PATCH v2 2/9] block: vhdx - add header update capability Jeff Cody
2013-08-01 13:44 ` Stefan Hajnoczi
2013-08-01 14:09 ` Jeff Cody [this message]
2013-08-07 14:42 ` Jeff Cody
2013-08-05 11:42 ` Kevin Wolf
2013-08-05 14:43 ` Jeff Cody
2013-08-05 14:45 ` Kevin Wolf
2013-08-05 14:57 ` Jeff Cody
2013-08-05 15:05 ` Kevin Wolf
2013-08-05 15:09 ` Jeff Cody
2013-08-06 8:34 ` Kevin Wolf
2013-08-01 3:23 ` [Qemu-devel] [PATCH v2 3/9] block: vhdx code movement - VHDXMetadataEntries and BDRVVHDXState to header Jeff Cody
2013-08-01 3:23 ` [Qemu-devel] [PATCH v2 4/9] block: vhdx - log support struct and defines Jeff Cody
2013-08-01 15:00 ` Stefan Hajnoczi
2013-08-01 15:51 ` Jeff Cody
2013-08-07 15:22 ` Kevin Wolf
2013-08-07 17:18 ` Jeff Cody
2013-08-01 3:23 ` [Qemu-devel] [PATCH v2 5/9] block: vhdx - break endian translation functions out Jeff Cody
2013-08-01 15:03 ` Stefan Hajnoczi
2013-08-01 15:14 ` Jeff Cody
2013-08-07 15:29 ` Kevin Wolf
2013-08-07 17:21 ` Jeff Cody
2013-08-01 3:23 ` [Qemu-devel] [PATCH v2 6/9] block: vhdx - update log guid in header, and first write tracker Jeff Cody
2013-08-01 15:09 ` Stefan Hajnoczi
2013-08-01 3:23 ` [Qemu-devel] [PATCH v2 7/9] block: vhdx - log parsing, replay, and flush support Jeff Cody
2013-08-01 3:23 ` [Qemu-devel] [PATCH v2 8/9] block: vhdx - add log write support Jeff Cody
2013-08-01 3:23 ` [Qemu-devel] [PATCH v2 9/9] block: vhdx " Jeff Cody
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130801140925.GI19714@localhost.localdomain \
--to=jcody@redhat.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.