Date: Fri, 10 Aug 2018 08:03:18 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 230493] sysutils/dvd+rw-tools: Cannot append data to BD-R DL used more than 25gb Message-ID: <bug-230493-7788-8xTi3hWzsr@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230493-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-230493-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230493 scdbackup@gmx.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |scdbackup@gmx.net --- Comment #5 from scdbackup@gmx.net --- Hi, ports r383719 / Ubuntu 1113679 is about a differnt bug, which caused an inappropriate command to be sent to the drive and consequentially an error reoly by the drive and an error message by growisofs. The mistake was that the BD-R was formatted automatically but growisofs still memorized the unformatted state. About the bug discussed here (Debian 615978): nwa =3D 0; if (buf[7]&1 && !bdr_plus_pow) // NWA_V { nwa =3D buf[12]<<24; nwa |=3D buf[13]<<16; nwa |=3D buf[14]<<8; nwa |=3D buf[15]; } free_blocks =3D buf[16]<<24; free_blocks |=3D buf[17]<<16; free_blocks |=3D buf[18]<<8; free_blocks |=3D buf[19]; ret =3D nwa + free_blocks; This obviously is meant to compute the total capacity of the medium, as sum of the effectively consumed blocks (Next Writable Address, NWA) and of the free blocks. Andy Polyakov expected the whole media capacity to be reported by the Free Blocks field of the drive's reply, because the BD-R is in state Pseudo-Overwrite, where all addresses are valid for writing. But the fact that the NWA_V bit in buf[7] is set announces a valid NWA and thus indicates that the drive does not count all blocks as free. --------------------------------------------------------------------- The only riddle that remains is why this bug is reported only with BD-R DL. MMC-5 4.5.3.6.4 gives an example which does not match the code neither with the fix nor without it. But the example situation differs somewhat from growisofs' doings. If i mentally move it towards growisofs, then the fixed code seems more plausible. All in all Pseudo-Overwrite is complicated and based on the mechanisms of Defect Management, which do not work very well when actually needed. I have a single-layer POW BD-R for testing purposes (so libburn-1.4.8 can refuse to write onto it). Indeed the drive reports to libburn for its "invisible" track a track description which would match the unfixed code: $ xorriso -scsi_log on -outdev /dev/cd0 ... READ TRACK INFORMATION 52 01 00 00 00 01 00 00 14 00=20 From drive: 20b 00 26 01 01 00 04 61 01 00 00 00 00 00 00 00 00 00 b4 74 00 5783 us [ 5021775 ] ... buf[7] is 0x01 here, NWA is 0x00000000, Free Blocks is 0x00b47400 =3D 11826176, which matches READ CAPACITY 0x00b473ff =3D 11826175. So for this medium, the unfixed code would work. The fixed code would work too, because NWA is 0. I failed yet to read from MMC specs that BD-R DL shall bevave different from BD-R. The statement of growisofs: builtin_dd of=3D/dev/pass1 obs=3D32k seek=3D1057160 indicates that the burn run was to start at block 16*1057160 =3D 16,914,560 which is already in the second layer. Have a nice day :) Thomas --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230493-7788-8xTi3hWzsr>