[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: BD-RE - can't create UDF on new disc


Thank you for creating xorriso. It's a really high quality program and it works great for my backups.

I haven't read every one of these emails, but do you think that this user could be having the well-known "udev polls the dvd" problem? That can cause a block device to appear to be read-only. Here's one hit from google (different symptom, but solution would be the same):



Thomas Schmitt wrote:

Gary Dale wrote:
dvd+rw-format -format /dev/sr0
* BD/DVD±RW/-RAM format utility by <appro@fy.chalmers.se>, version 7.1.
* 25.0GB BD media detected.
* formatting 59.5%
root@transponder:/home/garydale# mkudffs /dev/sr0
Error opening device: Read-only file system
dvd+rw-format -format /dev/sr0
* BD/DVD±RW/-RAM format utility by <appro@fy.chalmers.se>, version 7.1.
* 24.2GB BD media detected.
* formatting 0.0%:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN
PARAMETER LIST]: Input/output error

The 59.6 percent do not necessarily indicate failure.
dvd+rw-format gets these numbers from the drive while it waits
for the SCSI formatting command to finish. Many drives tell unrealistic
progress numbers with blanking or formatting.

More decisive is that no error was reported by dvd+rw-format.
So i would guess formatting succeeded.

You still see the two known problems:

- The drive refuses to re-format an already formatted BD-RE.
  This is not nice. But it is not to blame for your problems
  with the block device driver.

- mkudffs and other clients of the block device driver seem to
  perceive a read-only medium. But it is not read-only on drive level,
  as we can prove by using a burn program to write data onto it.
  Burn programs use the generic SCSI driver, not the block device

On August 10 you reported:

I did another test using system rescue cd. While it gives me
the same error when I run dvd+rw-format, I note that mkudffs
complains about multiple extents.

The second of the two problems showed a change in behavior.
The first one sits obviously in the drive and does not get
influenced by changing the system.

I assume that the second problem sits in the operating system.
So i advise you to boot the rescue system and to check whether
the medium can be written via the block device driver of that

  dd if=/dev/zero of=/dev/sr0 bs=2048 count=1

If this succeeds, then you could try to find out what mkudffs
has to complain. It might then be that the content of the
medium is disliked by mkudffs. If no progress can be made otherwise,
i would flood the medium with zeros and try mkudffs again:

  dd if=/dev/zero of=/dev/sr0 bs=2048 count=11826176

This will last about 40 - 100 minutes with 2x speed. It depends
on the quality of the drive how much effective speed it gets
from the checkreading which it performs on BD-RE while writing.

You can speed it up and get progress messages by letting xorriso
do the writing while it disables checkreading:

  dd if=/dev/zero bs=2048 count=11826176 |
  xorriso -as cdrecord -v dev=/dev/sr0 -nopad stream_recording=on -

But the central riddle remains:
Why does the block device driver of a Debian system suddenly decide
that the medium in the drive is incapable of writing ?
This behavior must have had a trigger. When did it begin and what
system changes were done around that time ?

Have a nice day :)


Reply to: