On 05/31/2015 03:54 PM, Mark Cave-Ayland wrote: > On 22/05/15 19:20, John Snow wrote: > >> As a post-script, can Darwin/PPC use a different mechanism for ATA at >> all, or is macio the sole ATA interface we support here? >> >> I want to see if I can pinpoint when a "good" bath and when a bad path >> diverges with respect to the disk contents ... >> >> Or if you have other ideas on how to identify the transfer that causes >> the issue, I'm all ears. > > After a fairly involved weekend, I've managed to track this one down. It > was an actually an issue with the chaining of write requests with > unaligned accesses, whereby alternating patterns of head, head/tail and > tail would end up overwriting the common remainder section and so copy > the wrong sector back to the disk. >
Great! > The bad news is that this has definitely been broken since QEMU 2.1+ so > anyone using a Darwin/OS X PPC image is very likely to have an > installation that won't boot, or corruption in an image if it was > originally installed on an older QEMU version :( > Bummer. On the other hand, the number of complaints I have seen is... zero. So here's hoping it isn't the apocalypse. > Note that as I figured out what was happening my code was morphing into > a very similar pattern to that of > bdrv_co_do_preadv()/bdrv_co_do_pwritev() (except mine still calculated > with sectors) and so I bit the bullet and moved them over to match the > existing style. This has the advantage that the algorithm is similar to > an existing one, plus if unaligned block APIs become available in the > future then switching them over should be fairly trivial. > > I'll post an updated patchset shortly. John, if you could confirm it > fixes the issue on your side that would be great. > > > ATB, > > Mark. > Sure thing. Had unexpected PTO last week, so give me a pinch to clear the todo list and I'll get to testing the patchset. --js
