Re: Spare Tables error on format
Hi, i wrote: > > Well, i seem to have more drives attached than you. :)) Listas Canal wrote: > I have 2 BD-RE and 1 DVD-RW, yes you have 1 more :)) But sr4 is drive number 5. And i have a sr5. 0 -dev '/dev/sr0' rwrw-- : 'HL-DT-ST' 'BDDVDRW GGC-H20L' 1 -dev '/dev/sr1' rwrw-- : 'HL-DT-ST' 'DVDRAM GH24NSC0' 2 -dev '/dev/sr2' rwrw-- : 'HL-DT-ST' 'BD-RE GGW-H20L' 3 -dev '/dev/sr3' rwrw-- : 'Optiarc ' 'BD RW BD-5300S' 4 -dev '/dev/sr4' rwrw-- : 'ASUS' 'BW-16D1HT' 5 -dev '/dev/sr5' rwrw-- : 'HL-DT-ST' 'BD-RE BH16NS40' > > Media summary: 610 sessions, 9060897 data blocks, 17.3g data, 5894m free > Did you recycle the one on the shelf when another 2 or more came? No. I still have them since i began using that scheme in 2010. Above backup has compression by zisofs and thus produces quite small sessions. In the beginning i used BD-R for it, but even the nicest burners refuse to burn more than about 300 session to them. With BD-RE there is no need for the drive to maintain an own table-of-content. It sees only one big track. So the chain of ISO 9660 sessions can get as long as the medium has capacity. > I hope BD-RE also has the > same durability or more for confidential data that grows from year to year. I recently performed BD-R tests by copying BD-REs of 2010, made by the GGW-H20L. (That old burner does not accept any contemporary BD-R for burning but still does bulk BD-RE backups for me with its sensational 2.3x speed.) Half of the copied BD-REs later turned out to be unreliable for writing. So my hope for a big recycling outcome was disappointed. But before that they all were readable and passed their MD5 content checks. On the other hand i have BD-RE from 2008 which get overwritten once every half year. > > (You could insert a command spy in method Scsi_Command.transport() > > of the file transport.hxx. The diff between original and spying version > > of transport.hxx has 179 lines. Ask me if you want to have it.) > Yes please, if you can share it as an attachment. I'm not sure whether this list takes attachments. So i will try by a separate mail. Have a nice day :) Thomas
Re: Spare Tables error on format
Hello Thomas
On Sat, Oct 30, 2021 at 3:15 AM Thomas Schmitt wrote:
> Hi,
>
> Listas Canal wrote:
> > user@mtrog64:~$ dvd+rw-format -f /dev/sr1 -ssa=262144000
> > ...
> > * formatting .:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN
> PARAMETER
> > LIST]: Input/output error
>
> My current theory is that this is because of formatting sub type 3 Quick
> Certification.
>
>
> Noted.!
> > user@mtrog64:~/Documentos/db/dvdrwtools/dvd-rw-tools$ ./dvd+rw-format
> > /dev/sr1 -force=full -ssa=min
> > ...
> > * formatting .:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN
> PARAMETER
> > LIST]: Input/output error
> >
> > Also commenting out the block for Quick Certification, does not work.
>
> So my theory seems wrong.
> Now it would be interesting to see what dvd+rw-format sent as cmd[0] to
> cmd[7] and as formats[i] to formats[i + 11].
>
> Yes
>
> > Wondering how you printf f[0]..f[7] I've tried as char and int, and I've
> got
> > different values per run.
>
> "char" is a tricky data type in C. It's signedness differs from CPU type
> to CPU type. SCSI bytes are meant unsigned and often are mentioned in
> the specs as hexadecimal XYh. So one should cast them to unsigned and use
> printf formatter %x or %X.
>
> Thank you I will try it
> I have in one of my modified versions of dvd+rw-format.cpp :
>
> { int j;
> fprintf(stderr, "BD-RE FORMAT command:");
> for (j = 0; j < 8; j++)
> fprintf(stderr, " %2.2x", (unsigned int) cmd[j]);
> fprintf(stderr, "\nParameter list:");
> for (j = 0; j < 12; j++)
> fprintf(stderr, " %2.2x", (unsigned int) formats[i + j]);
> fprintf(stderr, "\n");
> }
>
> It is inserted between
>
> if (full && (formats[i+4+4]>>2)!=0x31)
> formats[i+4+4] |= 2;// "Full Certificaton"
> else if ((formats[i+4+4]>>2)==0x30)
> formats[i+4+4] |= 3;// "Quick Certification"
>
> and
>
> if ((err=cmd.transport(WRITE,formats+i,12)))
> sperror ("FORMAT UNIT",err), exit(1);
>
> (You could insert a command spy in method Scsi_Command.transport()
> of the file transport.hxx. The diff between original and spying version
> of transport.hxx has 179 lines. Ask me if you want to have it.)
>
>
Yes please, if you can share it as an attachment.
> The meaning of the bytes is specified in SCSI volumes SPC and MMC.
> I wrote a guideline text
>
> https://dev.lovelyhq.com/libburnia/libburn/raw/branch/master/doc/cookbook.txt
Noted, great information. Downloaded!!!
>
> which quotes heavily from the meanwhile unavailable drafts of those
> specs. Regrettably T10 demands money for the PDFs of SPC and MMC and
> hid the drafts from the public. But
> https://en.wikipedia.org/wiki/MultiMedia_Commands
> has a link to a PDF which sits in a directory with old draft copies.
> (I do not mention its URL here, because else that last source of free
> SCSI wisdom could vanish, too.)
>
> Yes, also noted, I'll take a look. I've followed the link and has the doc.
> --
> Smalltalk and anecdotes:
>
> > libburn : FAILURE : File object '/dev/sr4' not found
>
> Well, i seem to have more drives attached than you. :))
>
> I have 2 BD-RE and 1 DVD-RW, yes you have 1 more :))
>
> > user@mtrog64:~$ xorriso -outdev /dev/sr1 -format fast_by_index_4
> > ...
> > user@mtrog64:~$ xorriso -outdev /dev/sr1 -list_formats
> > ...
> > Format status: formatted, with 23866.0 MiB
> > BD Spare Area: 0 blocks consumed, 0 blocks available
>
> I rarely use BD-RE without spare area. But given the poor performance
> of Defect Management it is plausible to do so, at least for single
> session use cases.
>
Yes in single session cases (BD-R or BD-RE) I also disable the spare area,
is nonsense. Clean discs or new, 1 single use.
> With multi-session i would propose minimal spare area because the
> emulation of multi-session needs to overwrite the first 64 blocks for
> each session. The other blocks get written only once until the medium
> is reused from scratch (after pseudo-blanking).
>
> Thanks for the advise, I use LUKS over the Blurays sometimes with UDF or
XFS, working perfect with small incremental backups, so I do prefer bigger
spare areas because I do not use ISO very often than in DVD-RW.
> I have a BD-RE which takes a small incremental update session every day
> since imeanwhile 20 months:
> Media summary: 610 sessions, 9060897 data blocks, 17.3g data, 5894m free
> Next spring or summer i will have to put it on the shelf and start with
> a blank BD-RE again.
>
> Did you recycle the one on the shelf when another 2 or more came?
>
> > I was enchanted by optical media, because the price/durability is more
> > affordable than SSD or USBs.
>
> I began to love them after a DAT tape drive at work turned out to have
> made bad backups for two years and the last usable backup was on an old
> QIC tape for which we had to buy a
Re: Spare Tables error on format
Hi,
Listas Canal wrote:
> user@mtrog64:~$ dvd+rw-format -f /dev/sr1 -ssa=262144000
> ...
> * formatting .:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN PARAMETER
> LIST]: Input/output error
My current theory is that this is because of formatting sub type 3 Quick
Certification.
> user@mtrog64:~/Documentos/db/dvdrwtools/dvd-rw-tools$ ./dvd+rw-format
> /dev/sr1 -force=full -ssa=min
> ...
> * formatting .:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN PARAMETER
> LIST]: Input/output error
>
> Also commenting out the block for Quick Certification, does not work.
So my theory seems wrong.
Now it would be interesting to see what dvd+rw-format sent as cmd[0] to
cmd[7] and as formats[i] to formats[i + 11].
> Wondering how you printf f[0]..f[7] I've tried as char and int, and I've got
> different values per run.
"char" is a tricky data type in C. It's signedness differs from CPU type
to CPU type. SCSI bytes are meant unsigned and often are mentioned in
the specs as hexadecimal XYh. So one should cast them to unsigned and use
printf formatter %x or %X.
I have in one of my modified versions of dvd+rw-format.cpp :
{ int j;
fprintf(stderr, "BD-RE FORMAT command:");
for (j = 0; j < 8; j++)
fprintf(stderr, " %2.2x", (unsigned int) cmd[j]);
fprintf(stderr, "\nParameter list:");
for (j = 0; j < 12; j++)
fprintf(stderr, " %2.2x", (unsigned int) formats[i + j]);
fprintf(stderr, "\n");
}
It is inserted between
if (full && (formats[i+4+4]>>2)!=0x31)
formats[i+4+4] |= 2;// "Full Certificaton"
else if ((formats[i+4+4]>>2)==0x30)
formats[i+4+4] |= 3;// "Quick Certification"
and
if ((err=cmd.transport(WRITE,formats+i,12)))
sperror ("FORMAT UNIT",err), exit(1);
(You could insert a command spy in method Scsi_Command.transport()
of the file transport.hxx. The diff between original and spying version
of transport.hxx has 179 lines. Ask me if you want to have it.)
The meaning of the bytes is specified in SCSI volumes SPC and MMC.
I wrote a guideline text
https://dev.lovelyhq.com/libburnia/libburn/raw/branch/master/doc/cookbook.txt
which quotes heavily from the meanwhile unavailable drafts of those
specs. Regrettably T10 demands money for the PDFs of SPC and MMC and
hid the drafts from the public. But
https://en.wikipedia.org/wiki/MultiMedia_Commands
has a link to a PDF which sits in a directory with old draft copies.
(I do not mention its URL here, because else that last source of free
SCSI wisdom could vanish, too.)
--
Smalltalk and anecdotes:
> libburn : FAILURE : File object '/dev/sr4' not found
Well, i seem to have more drives attached than you. :))
> user@mtrog64:~$ xorriso -outdev /dev/sr1 -format fast_by_index_4
> ...
> user@mtrog64:~$ xorriso -outdev /dev/sr1 -list_formats
> ...
> Format status: formatted, with 23866.0 MiB
> BD Spare Area: 0 blocks consumed, 0 blocks available
I rarely use BD-RE without spare area. But given the poor performance
of Defect Management it is plausible to do so, at least for single
session use cases.
With multi-session i would propose minimal spare area because the
emulation of multi-session needs to overwrite the first 64 blocks for
each session. The other blocks get written only once until the medium
is reused from scratch (after pseudo-blanking).
I have a BD-RE which takes a small incremental update session every day
since imeanwhile 20 months:
Media summary: 610 sessions, 9060897 data blocks, 17.3g data, 5894m free
Next spring or summer i will have to put it on the shelf and start with
a blank BD-RE again.
> I was enchanted by optical media, because the price/durability is more
> affordable than SSD or USBs.
I began to love them after a DAT tape drive at work turned out to have
made bad backups for two years and the last usable backup was on an old
QIC tape for which we had to buy a used drive to be able to read it.
I gained reputation by presenting new backups as ISO 9660 on CD which the
boss could put into his own desktop computer to check by normal means
whether his favorite files are there and readable. Especially he loved
that he could read the files but not alter them, and that he could read
the backup media at home.
Oh yeah. The late 1990s ...
Have a nice day :)
Thomas
Re: Spare Tables error on format
Sorry, it does not work:
Cloned from here: https://salsa.debian.org/optical-media-team/dvd-rw-tools
And applied all the patches
dvdrwtools/dvd-rw-tools$ for file in debian/patches/* ; do patch -p1 <
"$file"; done
patching file growisofs_mmc.cpp
patching file growisofs.1
patching file growisofs_mmc.cpp
patching file Makefile.m4
patching file growisofs.c
patching file transport.hxx
patching file growisofs.c
patching file growisofs.c
patching file growisofs.1
patching file index.html
patching file transport.hxx
patching file transport.hxx
patching file growisofs_mmc.cpp
patching file growisofs_mmc.cpp
Hunk #1 succeeded at 814 (offset 58 lines).
patching file growisofs.c
patching file transport.hxx
patching file growisofs_mmc.cpp
# make
user@mtrog64:~/Documentos/db/dvdrwtools/dvd-rw-tools$ ./dvd+rw-format
/dev/sr1 -force=full -ssa=min
* BD/DVD±RW/-RAM format utility by , version 7.1.
* 23.7GB BD media detected.
* formatting 0.0%:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN
PARAMETER LIST]: Input/output error
user@mtrog64:~/Documentos/db/dvdrwtools/dvd-rw-tools$ ./dvd+rw-format
/dev/sr1 -force=full -ssa=max
* BD/DVD±RW/-RAM format utility by , version 7.1.
* 23.7GB BD media detected.
* formatting .:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN PARAMETER
LIST]: Input/output error
Also commenting out the block for Quick Certification, does not work.
So, perhaps something is wrong in the FIELD construction.
Wondering how you printf f[0]..f[7] I've tried as char and int, and I've
got different values per run.
Kind regards
On Mon, Oct 25, 2021 at 7:33 AM Thomas Schmitt wrote:
> Hi,
>
> if you can afford to wait the up to 5000 seconds for a full format,
> then try
>
> dvd+rw-format -force=full /dev/sr0 -ssa=min
>
> -
> Long story:
>
> I found an old modified dvd+rw-tools directory which i used to spy on
> growisofs when i noticed behavior differences between it and libburn.
> (Substantial parts of libburn's DVD and BD knowledge was learned from
> dvd+rw-tools. But the need to see its actual SCSI transactions came up
> later when supporting growisofs users.)
>
> The failing SCSI command transaction is
>
> FORMAT UNIT
> 04 11 00 00 00 00
> To drive: 12b
> 00 82 00 08 00 b8 74 00 c3 00 10 00
> +++ key=5 asc=26h ascq=00h ( 4 ms)
>
> FOV bit and Immed bit are set in the Format List Header.
> 8 bytes are announced for the Format Descriptor, which requests 0xb87400
> = 12088320 blocks, which is indeed the largest possible payload and thus
> requests the smallest possible size of the Spare Area.
> Format Type is 0x30 (BD-R or BD-RE with spares).
> Format-Subtype is 3 (Quick Certification).
> Type Dependend Parameter is 0x00 0x010 0x00.
>
> Spying on libburn by
>
> xorriso -scsi_log on -outdev /dev/sr4 -format fast_by_index_3 \
> 2>&1 | tee -i /tmp/xorriso.log
>
> yields this successful transaction
>
> FORMAT UNIT
> 04 11 00 00 00 00
> To drive: 12b
> 00 82 00 08 00 b8 74 00 c0 00 10 00
>
> The only difference to dvd+rw-format is the Format-Subtype:
> 0 (Quick Reformat) instead of 3 (Quick Certification).
>
>
> Now i begin to find traces in libburn. A comment from 2008 says
>LG GGW-H20L YL03 refuses on 0x30 with
>"Quick certification". dvd+rw-format
>does 0x00 by default and succeeds quickly.
> Newer is a test for the Quick Certification flag in feature 23h,
> which would prevent Sub-type 3 if not set.
>
> Looking at
>
> https://sources.debian.org/src/dvd+rw-tools/7.1-14/dvd%252Brw-format.cpp/#L791
> which has
>
> if (full && (formats[i+4+4]>>2)!=0x31)
> formats[i+4+4] |= 2;// "Full Certificaton"
> else if ((formats[i+4+4]>>2)==0x30)
> formats[i+4+4] |= 3;// "Quick Certification"
>
> gives the idea that a run of
>
> dvd+rw-format -force=full /dev/sr0 -ssa=min
>
> might succeed.
>
> (My test BD-RE currently gets a -format by_index_3 run of xorriso and
> will be ready for more experiments in an hour and a half ...)
>
>
>
>
> If -force=full helps, then a patch candidate would be to replace
>
> formats[i+4+4] |= 3;// "Quick Certification"
>
> by a no-op (the 0 is already written to formats[i+4+4]):
>
> ; // "Quick Reformat" because "Quick Certification" often fails
>
> I am not sure whether this will work with all drives.
> Maybe better would be to inquire bit 2 of byte 4 of feature 23h from the
> GET CONFIGURATION command which already inquires the mmc_profile, i.e.
> the current media type and personality.
> If that bit is not set, then libburn uses Format Sub-Type 0 instead of 3
> or 2 ("Full Certification").
>
>
> Further i will have to find out why both softwares send a Type Dependend
> Parameter that is not all 0. Might be debris from the Format Descriptors
> which gets sent back to the drives. Only good that they gracefully ignore
> that 0x10 byte.
Re: Spare Tables error on format
Thankyou Thomas, evidently dvd+rw-format has an error in the source code, because there is no such value that satisfies a proper format inquiry. dvd+rw-format has a nice idea, about specifying the close spare area size, and finding the closest format index value, but fails. I did not have much knowledge like others of C/C++ or debugging hardware, but I will try with the hints you write in the next email. I've found BD-RE brand new from Japan, and I think it is the better than ever storage media for Cold Backups, since I have old, very old, CD-RW, or DVD-RW media intact, without any kind of data loss. Recently I've been involved in small projects about 1 month each, and I have to keep the information confidential and safe for as long as I can. So, that's because xorriso -outdev /dev/sr1 -format fast_by_index_2 saved my day. Thank you again, I really appreciate it. Here my experiment: user@mtrog64:~$ dvd+rw-format -f /dev/sr1 -ssa=262144000 * BD/DVD±RW/-RAM format utility by , version 7.1. * 24.2GB BD media detected. * formatting .:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN PARAMETER LIST]: Input/output error user@mtrog64:~$ dvd+rw-format -f /dev/sr0 -ssa=262144000 * BD/DVD±RW/-RAM format utility by , version 7.1. :-( mounted media doesn't appear to be DVD±RW, DVD-RAM or Blu-ray user@mtrog64:~$ dvd+rw-format -f /dev/sr1 -ssa=262144000 * BD/DVD±RW/-RAM format utility by , version 7.1. * 24.2GB BD media detected. * formatting .:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN PARAMETER LIST]: Input/output error user@mtrog64:~$ xorriso -outdev /dev/sr4 -list_formats xorriso 1.5.0 : RockRidge filesystem manipulator, libburnia project. libburn : FAILURE : File object '/dev/sr4' not found libburn : FAILURE : Cannot access '/dev/sr4' as SG_IO CDROM drive xorriso : FAILURE : Cannot acquire drive '/dev/sr4' xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE' user@mtrog64:~$ xorriso -outdev /dev/sr1 -list_formats xorriso 1.5.0 : RockRidge filesystem manipulator, libburnia project. Drive current: -outdev '/dev/sr1' Media current: BD-RE Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 22.6g free Drive current: -outdev '/dev/sr1' Media current: BD-RE Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 22.6g free Format status: formatted, with 23098.0 MiB BD Spare Area: 0 blocks consumed, 393216 blocks available Format idx 0 : 00h , 11826176s , 23098.0 MiB Format idx 1 : 30h , 11826176s , 23098.0 MiB Format idx 2 : 30h , 11564032s , 22586.0 MiB Format idx 3 : 30h , 12088320s , 23610.0 MiB Format idx 4 : 31h , 12219392s , 23866.0 MiB user@mtrog64:~$ dvd+rw-mediainfo /dev/sr1 INQUIRY:[PIONEER ][BD-RW BDR-209D][1.51] GET [CURRENT] CONFIGURATION: Mounted Media: 43h, BD-RE Media ID: CMCMAG/CN2 Current Write Speed: 2.0x4495=8990KB/s Write Speed #0:2.0x4495=8990KB/s Speed Descriptor#0:00/11826175 R@2.0x4495=8990KB/s W@2.0x4495=8990KB/s READ DISC INFORMATION: Disc status: complete Number of Sessions:1 State of Last Session: complete Number of Tracks: 1 READ FORMAT CAPACITIES: formatted: 11826176*2048=24220008448 00h(3000): 11826176*2048=24220008448 30h(3000): 11826176*2048=24220008448 30h(5000): 11564032*2048=23683137536 30h(1000): 12088320*2048=24756879360 31h(800): 12219392*2048=25025314816 READ TRACK INFORMATION[#1]: Track State: complete Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size:11826176*2KB FABRICATED TOC: Track#1 : 14@0 Track#AA : 14@11826176 Multi-session Info:#1@0 READ CAPACITY: 11826176*2048=24220008448 user@mtrog64:~$ xorriso -outdev /dev/sr1 -format fast_by_index_0 xorriso 1.5.0 : RockRidge filesystem manipulator, libburnia project. Drive current: -outdev '/dev/sr1' Media current: BD-RE Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 22.6g free Beginning to format medium. xorriso : UPDATE : Formatting ( 1.0% done in 1 seconds ) xorriso : UPDATE : Formatting ( 1.0% done in 2 seconds ) xorriso : UPDATE : Formatting ( 1.0% done in 3 seconds ) xorriso : UPDATE : Formatting ( 1.8% done in 4 seconds ) xorriso : UPDATE : Formatting ( 2.7% done in 5 seconds ) xorriso : UPDATE : Formatting ( 3.6% done in 6 seconds ) xorriso : UPDATE : Formatting ( 4.4% done in 7 seconds ) xorriso : UPDATE : Formatting ( 5.3% done in 8 seconds ) xorriso : UPDATE : Formatting ( 6.1% done in 9 seconds ) xorriso : UPDATE : Formatting ( 6.9% done in 10 seconds ) xorriso : UPDATE : Formatting ( 7.8% done in 11 seconds ) xorriso : UPDATE : Formatting ( 8.7% done in 12 seconds ) xorriso : UPDATE : Formatting ( 9.5% done in 13 seconds ) xorriso : UPDATE : Formatting ( 10.3% done in 14 seconds ) xorriso : UPDATE : Formatting ( 11.2% done in 15 seconds ) xorriso : UPDATE :
RE: EXTERNAL: Re: Spare Tables error on format
> Being developer of libburn and xorriso, i seem to be the last remaining > active carer of optical drives in the free software world. A lonely job. Civilization thanks you, Thomas -Eric J. Richardson -Original Message- From: Thomas Schmitt Sent: Monday, October 25, 2021 2:31 AM To: cdwrite@other.debian.org Subject: EXTERNAL: Re: Spare Tables error on format Hi, Listas Canal wrote: > Hello dear list:I don't know if here can I ask about dvd+rw-format, > the autor of dvd+rw-tools points this list. Well, he seems to be out of the burn business since a decade. Being developer of libburn and xorriso, i seem to be the last remaining active carer of optical drives in the free software world. A lonely job. > dvd+rw-tools-7.1$ ./dvd+rw-format -f /dev/sr0 -ssa=32m It looks like your -ssa= value is too small for BD-RE. MMC-5, 6.5.4.2.15.3 "Spares Allocation on Single Layer BD-RE" says that there must be at least 4096 * 32 = 131072 blocks = 256 MiB of spare area (or none at all). That paragraph predicts the error reply ILLEGAL REQUEST/INVALID FIELD IN PARAMETER LIST which you see with your run. It seems wrong that dvd+rw-format's understands your "32m" as 32.0e6, and then computes the desired number of blocks by dividing by 2.0e3. Actually block size is 2*1024. https://sources.debian.org/src/dvd+rw-tools/7.1-14/dvd%252Brw-format.cpp/#L285 So "32m" leads to 16,000 blocks instead of 16384. I expect that -ssa=262144000 yields the minimal permissible number of 131072 blocks. > only -ssa=none or -ssa=default is working. max and min also does not work. I did not use dvd+rw-format in years. $ dvd+rw-format -f /dev/sr4 -ssa=min * BD/DVD±RW/-RAM format utility by , version 7.1. * 24.5GB BD media detected. * formatting .:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN PARAMETER LIST]: Input/output error $ Wow. That was quick. With xorriso i would do it like: $ xorriso -outdev /dev/sr4 -list_formats ... Format status: formatted, with 23354.0 MiB BD Spare Area: 0 blocks consumed, 262144 blocks available Format idx 0 : 00h , 11826176s , 23098.0 MiB Format idx 1 : 30h , 11826176s , 23098.0 MiB Format idx 2 : 30h , 11564032s , 22586.0 MiB Format idx 3 : 30h , 12088320s , 23610.0 MiB Format idx 4 : 31h , 12219392s , 23866.0 MiB $ xorriso -outdev /dev/sr4 -format fast_by_index_3 ... Beginning to format medium. xorriso : UPDATE : Formatting ( 1.0% done in 1 seconds ) xorriso : UPDATE : Formatting ( 1.0% done in 2 seconds ) xorriso : UPDATE : Formatting ( 1.0% done in 3 seconds ) xorriso : UPDATE : Formatting ( 1.0% done in 4 seconds ) xorriso : UPDATE : Formatting ( 7.0% done in 5 seconds ) xorriso : UPDATE : Formatting ( 7.0% done in 6 seconds ) xorriso : UPDATE : Formatting ( 12.9% done in 7 seconds ) Formatting done ... $ xorriso -outdev /dev/sr4 -list_formats ... Format status: formatted, with 23610.0 MiB BD Spare Area: 0 blocks consumed, 131072 blocks available ... I fail to understand what goes wrong in dvd+rw-format with -ssa=min. The code is quite condensed but after some riddling it seems correct. It looks for the format descriptor with the highest capacity and uses its data to request that capacity via the FORMAT UNIT command. Pity that dvd+rw-format does not offer a debugging mode which would show its SCSI transactions, like with xorriso -scsi_log on. Whatever, even if we find the bug, there is few hope that Debian will add a patch to its dvd+rw-tools package. I have a DVD-R[W] patch pending there since 6 years. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794868 So i can only invite you to find the bugs in xorriso's formatting code. See above example and also the description of command -format in man xorriso. Have a nice day :) Thomas
Re: Spare Tables error on format
Hi,
if you can afford to wait the up to 5000 seconds for a full format,
then try
dvd+rw-format -force=full /dev/sr0 -ssa=min
-
Long story:
I found an old modified dvd+rw-tools directory which i used to spy on
growisofs when i noticed behavior differences between it and libburn.
(Substantial parts of libburn's DVD and BD knowledge was learned from
dvd+rw-tools. But the need to see its actual SCSI transactions came up
later when supporting growisofs users.)
The failing SCSI command transaction is
FORMAT UNIT
04 11 00 00 00 00
To drive: 12b
00 82 00 08 00 b8 74 00 c3 00 10 00
+++ key=5 asc=26h ascq=00h ( 4 ms)
FOV bit and Immed bit are set in the Format List Header.
8 bytes are announced for the Format Descriptor, which requests 0xb87400
= 12088320 blocks, which is indeed the largest possible payload and thus
requests the smallest possible size of the Spare Area.
Format Type is 0x30 (BD-R or BD-RE with spares).
Format-Subtype is 3 (Quick Certification).
Type Dependend Parameter is 0x00 0x010 0x00.
Spying on libburn by
xorriso -scsi_log on -outdev /dev/sr4 -format fast_by_index_3 \
2>&1 | tee -i /tmp/xorriso.log
yields this successful transaction
FORMAT UNIT
04 11 00 00 00 00
To drive: 12b
00 82 00 08 00 b8 74 00 c0 00 10 00
The only difference to dvd+rw-format is the Format-Subtype:
0 (Quick Reformat) instead of 3 (Quick Certification).
Now i begin to find traces in libburn. A comment from 2008 says
LG GGW-H20L YL03 refuses on 0x30 with
"Quick certification". dvd+rw-format
does 0x00 by default and succeeds quickly.
Newer is a test for the Quick Certification flag in feature 23h,
which would prevent Sub-type 3 if not set.
Looking at
https://sources.debian.org/src/dvd+rw-tools/7.1-14/dvd%252Brw-format.cpp/#L791
which has
if (full && (formats[i+4+4]>>2)!=0x31)
formats[i+4+4] |= 2;// "Full Certificaton"
else if ((formats[i+4+4]>>2)==0x30)
formats[i+4+4] |= 3;// "Quick Certification"
gives the idea that a run of
dvd+rw-format -force=full /dev/sr0 -ssa=min
might succeed.
(My test BD-RE currently gets a -format by_index_3 run of xorriso and
will be ready for more experiments in an hour and a half ...)
If -force=full helps, then a patch candidate would be to replace
formats[i+4+4] |= 3;// "Quick Certification"
by a no-op (the 0 is already written to formats[i+4+4]):
; // "Quick Reformat" because "Quick Certification" often fails
I am not sure whether this will work with all drives.
Maybe better would be to inquire bit 2 of byte 4 of feature 23h from the
GET CONFIGURATION command which already inquires the mmc_profile, i.e.
the current media type and personality.
If that bit is not set, then libburn uses Format Sub-Type 0 instead of 3
or 2 ("Full Certification").
Further i will have to find out why both softwares send a Type Dependend
Parameter that is not all 0. Might be debris from the Format Descriptors
which gets sent back to the drives. Only good that they gracefully ignore
that 0x10 byte.
Have a nice day :)
Thomas
Re: Spare Tables error on format
Hi, Listas Canal wrote: > Hello dear list:I don't know if here can I ask about dvd+rw-format, the > autor of dvd+rw-tools points this list. Well, he seems to be out of the burn business since a decade. Being developer of libburn and xorriso, i seem to be the last remaining active carer of optical drives in the free software world. A lonely job. > dvd+rw-tools-7.1$ ./dvd+rw-format -f /dev/sr0 -ssa=32m It looks like your -ssa= value is too small for BD-RE. MMC-5, 6.5.4.2.15.3 "Spares Allocation on Single Layer BD-RE" says that there must be at least 4096 * 32 = 131072 blocks = 256 MiB of spare area (or none at all). That paragraph predicts the error reply ILLEGAL REQUEST/INVALID FIELD IN PARAMETER LIST which you see with your run. It seems wrong that dvd+rw-format's understands your "32m" as 32.0e6, and then computes the desired number of blocks by dividing by 2.0e3. Actually block size is 2*1024. https://sources.debian.org/src/dvd+rw-tools/7.1-14/dvd%252Brw-format.cpp/#L285 So "32m" leads to 16,000 blocks instead of 16384. I expect that -ssa=262144000 yields the minimal permissible number of 131072 blocks. > only -ssa=none or -ssa=default is working. max and min also does not work. I did not use dvd+rw-format in years. $ dvd+rw-format -f /dev/sr4 -ssa=min * BD/DVD±RW/-RAM format utility by , version 7.1. * 24.5GB BD media detected. * formatting .:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN PARAMETER LIST]: Input/output error $ Wow. That was quick. With xorriso i would do it like: $ xorriso -outdev /dev/sr4 -list_formats ... Format status: formatted, with 23354.0 MiB BD Spare Area: 0 blocks consumed, 262144 blocks available Format idx 0 : 00h , 11826176s , 23098.0 MiB Format idx 1 : 30h , 11826176s , 23098.0 MiB Format idx 2 : 30h , 11564032s , 22586.0 MiB Format idx 3 : 30h , 12088320s , 23610.0 MiB Format idx 4 : 31h , 12219392s , 23866.0 MiB $ xorriso -outdev /dev/sr4 -format fast_by_index_3 ... Beginning to format medium. xorriso : UPDATE : Formatting ( 1.0% done in 1 seconds ) xorriso : UPDATE : Formatting ( 1.0% done in 2 seconds ) xorriso : UPDATE : Formatting ( 1.0% done in 3 seconds ) xorriso : UPDATE : Formatting ( 1.0% done in 4 seconds ) xorriso : UPDATE : Formatting ( 7.0% done in 5 seconds ) xorriso : UPDATE : Formatting ( 7.0% done in 6 seconds ) xorriso : UPDATE : Formatting ( 12.9% done in 7 seconds ) Formatting done ... $ xorriso -outdev /dev/sr4 -list_formats ... Format status: formatted, with 23610.0 MiB BD Spare Area: 0 blocks consumed, 131072 blocks available ... I fail to understand what goes wrong in dvd+rw-format with -ssa=min. The code is quite condensed but after some riddling it seems correct. It looks for the format descriptor with the highest capacity and uses its data to request that capacity via the FORMAT UNIT command. Pity that dvd+rw-format does not offer a debugging mode which would show its SCSI transactions, like with xorriso -scsi_log on. Whatever, even if we find the bug, there is few hope that Debian will add a patch to its dvd+rw-tools package. I have a DVD-R[W] patch pending there since 6 years. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794868 So i can only invite you to find the bugs in xorriso's formatting code. See above example and also the description of command -format in man xorriso. Have a nice day :) Thomas
