Alternate proposed logic for fs-update unused blocks optimisation
quozl at laptop.org
Wed Apr 20 21:38:23 EDT 2011
On Wed, Apr 20, 2011 at 05:18:50PM +1000, James Cameron wrote:
> There is one small problem left to fix; Q3A64 fs-update displays an
> error at the end because the total number of blocks written has not
> agreed with the number of blocks specified at the top of the file. I
> propose to fix that somehow, but I've yet to decide on exactly how.
> It was introduced by -r2186, where on your request Mitch changed the
> check from last block written to number of blocks written. It does
> not happen with Q3A62.
I've fixed this locally and tested with my sparse .zd file, and
os860.zd. The patch is attached for review.
I've changed the ?all-written check, which happens after the blocks are
written, so that it reports a warning if either:
- the highest block written is below the end of the image, and/or;
- the lowest block written is not zero.
For an fs-update of a sparse .zd file, using a partial download, the
first warning appears after "Short read of zdata file".
For an fs-update of a zero block last .zd file, using a partial
download, both warnings shall appear.
This changes the meaning of the #image-eblocks value from a count of
blocks expected, to a count of blocks in the original image from which
the .zd was made.
(Also, in the previous code, #eblocks-written was not reset when
fs-update started, so I suspect a second fs-update would have generated
a spurious warning.)
Do you have a sample of your "write zero block last" .zd file? I've
looked at os16.zd2.zsp but it writes zero block first. I really should
set up an F14 builder here. Got any checklist?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1729 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/devel/attachments/20110421/249f624a/attachment.patch
More information about the Devel