Re: Question regarding correct linux cdrecord device and buffer issues.
Khelben Blackstaff <eye.of.the.8eholder@gmail.com> wrote:
> I have some questions about dvd burning with cdrecord.
>
> 1)
> The device choice was always a gray area in linux but in older times
> it was more clear. With 2.4 linux kernel there was ide-scsi support.
> With early 2.6 there was dev=ATAPI:x,y,z.
>
> Nowadays with recent kernels (for example 2.6.28) i can use two namings.
> The /dev/sr0 and the usual x,y,z naming.
>
> I tried to read the archives and came to believe that using dev=x,y,z is
> better than dev=/dev/sr0. Is that correct ?
/dev/sr0 is unsupported, you should not rely on it and it may stop working
tomorrow.
The dev=b,t,l syntax is supported in libscg since 23.5 years now, this is much
longer than Linux exists.... The problem that results from Linux changing it's
kernel interfaces in an incompatible way is hidden by libscg.
> 2) There are some things about the buffer in the cdrecord output that i
> don't understand. The command i use is "cdrecord -v -dao file_to_write"
> and the output is the following.
>
> Cdrecord-ProDVD-ProBD-Clone 2.01.01a53 (i686-pc-linux-gnu) Copyright
> (C) 1995-2008 Jï¿?rg Schilling TOC Type: 1 = CD-ROM
> scsidev: '/dev/dvdrw'
> devname: '/dev/dvdrw'
You are using an unsupported dev= parameter and you are using an outdated
cdrecord version.
> Min drive buffer fill was 98%
> Fixating...
> Fixating time: 36.096s
> BURN-Free was 20 times used.
> cdrecord: fifo had 46333 puts and 46333 gets.
> cdrecord: fifo was 0 times empty and 6481 times full, min fill was 43%.
> 2a)
> The question i have is why BURN-Free was used when the buffer wasn't
> empty ? In one time it is 43% and in the other time 95%
> Isn't burnfree used when the buffer is empty ?
With a53, I tried to do the FreeBSD people a favor and increased the default
buffer size in hope to better support BluRay. This caused problems on Linux and
Solaris and I had to go back to the old values. On Linux, a kernel bug causes
the DMA speed to be significantly reduced in case that the DMA size is > 62 kB.
You should upgrade.
> 2c) It is reducing the transfer size from 129024 to 98304 bytes.
> I read in the a54 changelog that the transfer size was reverted to 63kb
> because the kernel can't handle it. Is this the same thing ?
> Does this reducing to 98304 cause any problems ?
This is related to media support and not to kernel problems.
> cdrecord -scanbus output is the following:
>
> Cdrecord-ProDVD-ProBD-Clone 2.01.01a53 (i686-pc-linux-gnu) Copyright
> (C) 1995-2008 Jörg Schilling Using libscg version 'schily-0.9'.
> scsibus2:
> 2,0,0 200) 'TSSTcorp' 'CDDVDW SH-S223Q ' 'SB02' Removable
> CD-ROM
> 2,1,0 201) *
> 2,2,0 202) *
> 2,3,0 203) *
> 2,4,0 204) *
> 2,5,0 205) *
> 2,6,0 206) *
> 2,7,0 207) *
>
> /etc/default/cdrecord is the following:
> #ident @(#)cdrecord.dfl 1.4 02/07/07 Copyr 1998 J. Schilling
> CDR_DEVICE=samsung
> CDR_FIFOSIZE=16m
> # drive name device speed fifosize driveropts
> samsung= /dev/dvdrw -1 32m burnfree
Why did you change /etc/default/cdrecord and add an unsupported device entry?
.. or is this a bug introduced by slackware?
If you only have one drive, you do not need a file /etc/default/cdrecord at all
as cdrecord then searches for the drive.
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Reply to: