Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

Jens Axboe
2003-11-06T09:59:22Z

On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> Jens Axboe wrote:
> >(cc me, just caught your message by luck)
> >
> >On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> >
> >>>>>it's a cdrecord option, I've never used k3b so cannot comment on how to
> >>>>>make it enable that.
> >>>>
> >>>>Hmm, I'll take a look, but I don't really think it is a problem of the
> >>>>recording programme, otherwise how could my reader read it out
> >>>>completely?
> >>>
> >>>
> >>>It isn't a problem of the recorder program. But some drives wont read
> >>>the very end of a disc unless there are some pad blocks at the end.
> >>>Thus, you should always use the cdrecord pad option.
>
> Well, I now used the -pad option, but now the image (naturally) gets
> larger and thus k3b reports verify fail. I think the k3b people need to
> ignore the last 00s and calc the md5sum according to the original iso
> size...

Sounds right, yes.

> >>>Don't remember, sorry :)
> >>
> >>I probably will make a new topic regarding issues (I think) I found with
> >>the new mm kernel.
> >
> >
> >Fine, check the SG_IO thing first though.
>
> I am sorry, but could you explain how to find out? I dunno where to
> look... But I made your vmstat output:

Your other mail showed the device argument being the actual device, so
unless cdrecord screws, it is using SG_IO.

> procs -----------memory---------- ---swap-- -----io---- --system--
> ----cpu----
> r b swpd free buff cache si so bi bo in cs us
> sy id wa
> 2 0 0 579472 13976 308572 0 0 425 85 1255 645 5
> 3 84 9
> 2 0 0 579456 13976 308572 0 0 0 0 725 521 5
> 5 91 0
> 1 0 0 579448 13976 308572 0 0 0 0 736 523 2
> 5 94 0
> 0 0 0 579448 13976 308572 0 0 0 25 745 439 2

[snip]

This looks good, from a system utilization point of view. I'm wondering
whether you have the iso image cached? There's no block io going on.

It does like more like a CPU scheduler problem at this point.

--
Jens Axboe