Re: BD-RE mount problem
Hi,
While I have no direct experience with it, there is a kernel tracing
facility called System Tap (http://sourceware.org/systemtap/), which I've
heard folks can use to observe the behavior of a running kernel. You may
be able to selectively trace open calls that fail in the fashion you
desire using it.
/ken
On 08/10/2012 03:59 AM, Thomas Schmitt wrote:
> 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
>
>
Reply to: