FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 08-10-2012, 09:35 AM
Gary Dale
 
Default BD-RE mount problem

On 10/08/12 05:23 AM, Thomas Schmitt wrote:

Hi,


- fd = open("/dev/sr0", O_RDWR);
+ fd = open("/dev/sr0", O_RDWR | O_NDELAY);

open: fd= 3 , errno= 0
write: ret= 2048 , errno= 0

This explains why xorriso or dvd+rw-format can open the drive
device file. (The failure to re-format is a different problem.)



No one in Debian user has been able to shed any light on the problem.

I am not a kernel hacker, but rather a self-proclaimed expert for
optical drives and ISO 9660.

My best guess is that the kernel believes the medium is read-only
(like BD-ROM) and thus refuses any attempt to use it for writing
via the normal POSIX system interface.

But i do not know how to inquire the kernel's view on the medium.
The drive sees a BD-RE and has no scruples to write data to it.
But the kernel seems to see a problem with writing.


Thanks Thomas.

I'm wondering if the problem is the iso9660 file system that K3B put
onto the disc? That would make the medium read-only so far as normal
file I/O is concerned. Perhaps when faced with read-only media, the
kernel simply assumes that the device itself is read-only.



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 5024D5E9.4090005@rogers.com">http://lists.debian.org/5024D5E9.4090005@rogers.com
 
Old 08-10-2012, 10:59 AM
"Thomas Schmitt"
 
Default BD-RE mount problem

Hi,

> I'm wondering if the problem is the iso9660 file system that K3B put onto
> the disc?

I seriously doubt.
At least dd should have no scruples to overwrite any filesystem.

The block device driver has no idea of filesystems.
The only connection would be open(2) flag O_EXCL. mount uses it
to tell others that the drive is in use. To learn about it, the
other program would have to use O_EXCL, too, But open_sr0.c
does not do that and even if so, then it would cause error 16 EBUSY
rather than 30 EROFS.

The problem seems to be in the way how the kernel perceives the
drive or the medium.


> Perhaps when faced with read-only media, the kernel simply
> assumes that the device itself is read-only.

That would be an expensive one-way-road for re-usable media.

Drive and medium appear as one thing to the software which controls
the drive. The medium type is expressed by the SCSI "profile" number.
This is not exactly a medium type identifier but a promise that the
drive can perform certain actions on the loaded medium.
In a write-capable drive a BD-RE should cause profile 0x43.
In a read-only drive, a BD-RE might well appear as 0x40 BD-ROM.

But we know from dvd+rw-format and xorriso that the drive reports
profile 0x43 = BD-RE and that one can write data onto the medium.
So for some reason the kernel (actually the block device driver)
seems to get it wrong.


Well, maybe the refusal has other reasons.
One approach would be to debug the kernel: insert printk() and
compile and reboot. Multiple times.
It would be tricky to do this in a virtual machine, but not impossible.
See
http://libburnia-project.org/wiki/QemuXorriso

I recently did a similar try-and-error research on Debian squeeze
in order to find out why Linux would not mount the HFS+ aspect of
a xorriso hybrid image. (It turned out that the kernel has hardcoded
APM block size 512, whereas xorriso used 2048 by default.)
To my luck, i could use qemu for the development cycles.

This is not a task where i can help from remote.
One would have to find the occasions where error 30 (EROFS) is
emitted during the course of open(2).
Each of them would have to be equipped by printk() which puts text
into the system log (dmesg, /var/log/messages, ...).
Then you try from userspace to open("/dev/sr0", O_RDWR); and look
in the log for messages from your printk().

Theories will emerge and fail. If you are lucky then you find out
enough to revert the system change that has hit you. (Obviously
something must have triggered the change in behavior.)

Or you can send a request for help to Linux Kernel Mailing List,
which is a rough territory if one is not well prepared. Especially
since Debian kernels are usually not the newest ones.


Have a nice day

Thomas


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 12645612483761152932@scdbackup.webframe.org">http://lists.debian.org/12645612483761152932@scdbackup.webframe.org
 
Old 08-10-2012, 02:33 PM
"Thomas Schmitt"
 
Default BD-RE mount problem

Hi,

i can reproduce the symptoms by a read-only situation of drive and
media. (It should not happen with BD-RE in a BD writer, of course.)

open_sr0.c with O_NDELAY yielded:
> open: fd= 3 , errno= 0
> write: ret= 2048 , errno= 0

I get the same behavior when i put a DVD into a DVD-ROM drive.
It allows me to dump my data into a black hole and reports no error
to the userspace program.
In /var/log/messages i find

sr 6:0:0:0: [sr1] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sr 6:0:0:0: [sr1] Sense Key : Illegal Request [current]
sr 6:0:0:0: [sr1] Add. Sense: Invalid command operation code
sr 6:0:0:0: [sr1] CDB: Write(10): 2a 00 00 00 00 00 00 00 01 00
lost page write due to I/O error on sr1

Looks like an old kernel bug resp. unwanted way to silently
shoot your own foot.
It happens too with 8 subsequent write() calls with sleep(1) inbetween.
No delayed error is returned.


-------------------------------------------------------------------

I dug out the reason why libburn (underneath xorriso) uses O_NDELAY
when it opens the drive device file.

A note to myself in libburn/sg-linux.c:

O_NONBLOCK is prescribed by <linux/cdrom.h>
Switched to O_NDELAY for LKML statement 2007/4/11/141 by Alan Cox:
"open() has side effects. The CD layer allows you to open
with O_NDELAY if you want to avoid them."

In Debian squeeze's /usr/include/linux/cdrom.h:

* Additionally, as of Linux 2.1.x, all Linux application programs
* should use the O_NONBLOCK option when opening a CD-ROM device
* for subsequent ioctl commands. This allows for neat system errors
* like "No medium found" or "Wrong medium type" upon attempting to
* mount or play an empty slot, mount an audio disc, or play a data disc.

This explains why open() does not fail with O_NDELAY (= O_NOBLOCK):
For ioctl(SG_IO) one needs w-permission. So it must tolerate
O_RDWR | O_NDELAY
But why does not write(2) fail afterwards ?


Have a nice day

Thomas


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 14098612380822626538@scdbackup.webframe.org">http://lists.debian.org/14098612380822626538@scdbackup.webframe.org
 
Old 08-10-2012, 04:46 PM
Gary Dale
 
Default BD-RE mount problem

On 10/08/12 10:33 AM, Thomas Schmitt wrote:

Hi,

i can reproduce the symptoms by a read-only situation of drive and
media. (It should not happen with BD-RE in a BD writer, of course.)

open_sr0.c with O_NDELAY yielded:

open: fd= 3 , errno= 0
write: ret= 2048 , errno= 0

I get the same behavior when i put a DVD into a DVD-ROM drive.
It allows me to dump my data into a black hole and reports no error
to the userspace program.
In /var/log/messages i find

sr 6:0:0:0: [sr1] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sr 6:0:0:0: [sr1] Sense Key : Illegal Request [current]
sr 6:0:0:0: [sr1] Add. Sense: Invalid command operation code
sr 6:0:0:0: [sr1] CDB: Write(10): 2a 00 00 00 00 00 00 00 01 00
lost page write due to I/O error on sr1

Looks like an old kernel bug resp. unwanted way to silently
shoot your own foot.
It happens too with 8 subsequent write() calls with sleep(1) inbetween.
No delayed error is returned.


-------------------------------------------------------------------

I dug out the reason why libburn (underneath xorriso) uses O_NDELAY
when it opens the drive device file.

A note to myself in libburn/sg-linux.c:

O_NONBLOCK is prescribed by<linux/cdrom.h>
Switched to O_NDELAY for LKML statement 2007/4/11/141 by Alan Cox:
"open() has side effects. The CD layer allows you to open
with O_NDELAY if you want to avoid them."

In Debian squeeze's /usr/include/linux/cdrom.h:

* Additionally, as of Linux 2.1.x, all Linux application programs
* should use the O_NONBLOCK option when opening a CD-ROM device
* for subsequent ioctl commands. This allows for neat system errors
* like "No medium found" or "Wrong medium type" upon attempting to
* mount or play an empty slot, mount an audio disc, or play a data disc.

This explains why open() does not fail with O_NDELAY (= O_NOBLOCK):
For ioctl(SG_IO) one needs w-permission. So it must tolerate
O_RDWR | O_NDELAY
But why does not write(2) fail afterwards ?


Have a nice day

Thomas
I did try this when booting from System Rescue CD (sub stick) as well. I
get the same results. I'm hoping to get another system up and running
next week that also has a BluRay writer. I'll give that a try too.


Thanks.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 50253AF7.7080503@rogers.com">http://lists.debian.org/50253AF7.7080503@rogers.com
 
Old 08-10-2012, 06:50 PM
Gary Dale
 
Default BD-RE mount problem

On 10/08/12 12:46 PM, Gary Dale wrote:

On 10/08/12 10:33 AM, Thomas Schmitt wrote:

Hi,

i can reproduce the symptoms by a read-only situation of drive and
media. (It should not happen with BD-RE in a BD writer, of course.)

open_sr0.c with O_NDELAY yielded:

open: fd= 3 , errno= 0
write: ret= 2048 , errno= 0

I get the same behavior when i put a DVD into a DVD-ROM drive.
It allows me to dump my data into a black hole and reports no error
to the userspace program.
In /var/log/messages i find

sr 6:0:0:0: [sr1] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sr 6:0:0:0: [sr1] Sense Key : Illegal Request [current]
sr 6:0:0:0: [sr1] Add. Sense: Invalid command operation code
sr 6:0:0:0: [sr1] CDB: Write(10): 2a 00 00 00 00 00 00 00 01 00
lost page write due to I/O error on sr1

Looks like an old kernel bug resp. unwanted way to silently
shoot your own foot.
It happens too with 8 subsequent write() calls with sleep(1) inbetween.
No delayed error is returned.


-------------------------------------------------------------------

I dug out the reason why libburn (underneath xorriso) uses O_NDELAY
when it opens the drive device file.

A note to myself in libburn/sg-linux.c:

O_NONBLOCK is prescribed by<linux/cdrom.h>
Switched to O_NDELAY for LKML statement 2007/4/11/141 by
Alan Cox:

"open() has side effects. The CD layer allows you to open
with O_NDELAY if you want to avoid them."

In Debian squeeze's /usr/include/linux/cdrom.h:

* Additionally, as of Linux 2.1.x, all Linux application programs
* should use the O_NONBLOCK option when opening a CD-ROM device
* for subsequent ioctl commands. This allows for neat system errors
* like "No medium found" or "Wrong medium type" upon attempting to
* mount or play an empty slot, mount an audio disc, or play a data
disc.


This explains why open() does not fail with O_NDELAY (= O_NOBLOCK):
For ioctl(SG_IO) one needs w-permission. So it must tolerate
O_RDWR | O_NDELAY
But why does not write(2) fail afterwards ?


Have a nice day

Thomas
I did try this when booting from System Rescue CD (sub stick) as well.
I get the same results. I'm hoping to get another system up and
running next week that also has a BluRay writer. I'll give that a try
too.


Thanks.


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. I don't know why it gives a different message under
system rescue cd than under Debian/Wheezy but I thought it might be a
clue as to what the problem is.






--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 50255809.3020809@rogers.com">http://lists.debian.org/50255809.3020809@rogers.com
 
Old 08-11-2012, 05:58 AM
"Thomas Schmitt"
 
Default BD-RE mount problem

Hi,

> 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. I don't know why it gives a different message under system rescue
> cd than under Debian/Wheezy but I thought it might be a clue as to what the
> problem is.

What do you get from a plain write attempt:

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


Have a nice day

Thomas


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 8757612425536751145@scdbackup.webframe.org">http://lists.debian.org/8757612425536751145@scdbackup.webframe.org
 

Thread Tools




All times are GMT. The time now is 03:35 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org