Bug 409504

Reiserfs does check whether the device is read-only, but the DVD drive isn't reporting itself as read-only. It's probably a writer as well? The media change event doesn't change the read-write status of the device, probably because that logic doesn't really belong in the kernel.

The problem you're running into is that reiserfs is trying to initialize the journal, which the media is rejecting due to it being read-only.

Just add "ro" to the list of options in /etc/fstab.

I'm going to assign this to Tejun since I expect it's causing a few other problems with read-only media where the file system is assuming that it's read-write.

Tejun, if there's a technical reason why this can't happen in the kernel (or a previous argument where this has already been decided) I'd like to hear it.

The fstab has already "ro" (see #1), but yes, it is a dvd burner drive.

I think I saw this before [...] Yes, I reported a similar or same problem with XFS, Bug 280900, comment 4

Hmmm.... Whether a mmc device can be opened r/w or not is determined at open time in cdrom_open_write().  The code has been quite stable and I don't really know why or how they got shaped into the current form, but the traditional writable semantics doesn't always fit.  DVD RAM device is writable alright but is a recorded re-writable media writable or not?  ie. A recording program would want to open the device RW, issue blank command followed by writes but other programs which blindly issue writes without blanking will fail.  Writing to MMC devices is pretty complex and I suppose that's why the kernel tries to be permissive and let the users decide as the kernel doesn't know much about writing anyway.  Writing is usually between the drive firmware and userland burning app.  Another example would be a partially written media which a knowledgeable burning app can append new sessions but dumb WRITE(10)s would just fail.

That said, the reported problem is pretty stinky.  Maybe there needs to be a distinction between randomly writable and recordable.  Hmmm... How come the 'ro' flag doesn't work?

I don't think we can come up with a good kernel-side fix for this problem soon.  Jeff, do you have any idea why the ro flag didn't work?

Yeah, the file system treats bdev_read_only() and MS_RDONLY differently. bdev_read_only() is a hard read-only while MS_RDONLY is a logical read-only. If there are outstanding transactions in the journal, it must flush them before continuing.

I have a patch that I accidentally didn't send upstream or apply to opensuse that handles bdev_read_only() more gracefully but I'm not sure it would help here.

I've posted a 10.3 i386 default kernel at http://ftp.suse.com/pub/people/jeffm/suse/testpkgs/409504/10.3-i386/ Could you give it a try?

I'm about to start my vacations tomorrow, I don't know if I'll be able to test it. But I'm downloading it to try on the next reboot.

Ok, I found some time while watching a boring movie. It doesn't work, I'm afraid.

nimrodel:~ # uname -a
Linux nimrodel 2.6.22.18-_bug409504-default #1 SMP 2008-08-04 16:57:59 +0200 i686 i686 i386 GNU/Linux
nimrodel:~ # /etc/init.d/boot.crypto start /dev/dvd.l
Please enter passphrase for /dev/dvd.l (mycrypt_mm_dvd):
key slot 0 unlocked.
Please enter passphrase for /dev/dvd.l (mycrypt_mm_dvd): Command successful.
/dev/dvd.l...                                                         done
nimrodel:~ #


**** /var/log/kernel

Aug  5 02:16:09 nimrodel kernel: eth0: no IPv6 routers present
Aug  5 02:16:09 nimrodel kernel: audit(1217895367.059:68): audit_pid=4402 old=0 by auid=4294967295
Aug  5 02:16:18 nimrodel kernel: NET: Registered protocol family 17
Aug  5 02:16:18 nimrodel kernel: device eth0 entered promiscuous mode
Aug  5 02:16:38 nimrodel kernel: PPP generic driver version 2.4.2
Aug  5 02:19:19 nimrodel kernel: REISERFS (device dm-1): found reiserfs format "3.6" with standard journal
Aug  5 02:19:19 nimrodel kernel: REISERFS (device dm-1): using ordered data mode
Aug  5 02:19:19 nimrodel kernel: reiserfs: using flush barriers
Aug  5 02:19:19 nimrodel kernel: REISERFS (device dm-1): journal params: device dm-1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
Aug  5 02:19:19 nimrodel kernel: REISERFS (device dm-1): checking transaction log (dm-1)
Aug  5 02:19:20 nimrodel kernel: reiserfs: disabling flush barriers on dm-1
Aug  5 02:19:20 nimrodel kernel: REISERFS (device dm-1): Using r5 hash to sort names
Aug  5 02:19:29 nimrodel kernel: hdc: command error: status=0x51 { DriveReady SeekComplete Error }
Aug  5 02:19:29 nimrodel kernel: hdc: command error: error=0x50 { LastFailedSense=0x05 }
Aug  5 02:19:29 nimrodel kernel: ide: failed opcode was: unknown
Aug  5 02:19:29 nimrodel kernel: ATAPI device hdc:
Aug  5 02:19:29 nimrodel kernel:   Error: Illegal request -- (Sense key=0x05)
Aug  5 02:19:29 nimrodel kernel:   Invalid field in command packet -- (asc=0x24, ascq=0x00)
Aug  5 02:19:29 nimrodel kernel:   The failed "Write 10" packet command was:
Aug  5 02:19:29 nimrodel kernel:   "2a 00 00 00 41 26 00 00 02 00 00 00 00 00 00 00 "
Aug  5 02:19:29 nimrodel kernel: end_request: I/O error, dev hdc, sector 66712
Aug  5 02:19:29 nimrodel kernel: Buffer I/O error on device hdc, logical block 8339
Aug  5 02:19:29 nimrodel kernel: lost page write due to I/O error on hdc



Some notes to clarify things a bit, just in case.

The dvd contains a reiserfs image, encrypted. 

cer@nimrodel:~> file -s /dev/hdc
/dev/hdc: LUKS encrypted file, ver 1 [aes, cbc-essiv:sha256, sha1] UUID: bcfe5715-c092-4fea-b2dc-7951cb2

The image was first generated as a HD filesystem on a file which can be normally mounted via "/etc/init.d/boot.crypto start IMAGEFILE". Data is copied there, then umounted ("boot.crypto stop IMAGEFILE"), then the IMAGEFILE is burned normally to the dvd. The journal should thus not have anything pending. 

It looks as if the system tries to activate the journal, sees it can't write to it, and continues happily. The doubt is what would happen on a hard disk partition mounted RO: think of somebody doing a forensic analysis, what would happens if the kernel writes to it...

openSUSE 10.3 is no longer supported. Please test this issue against openSUSE 11.3 and reopen if it persists. Thank you.

Indeed, the problem remains in 11.2

Opened new Bugzilla -> Bug 647322 - System writes to a loop mount of a RO image.

Somebody else reported a variant of this in 11.3, which I have left up to him to report.

I reopen this just to trigger your attention, then please close it again, and try to solve the new bug instead. Don't leave it forgotten till 11.3 is in turn unsupported.

Ok, I've noted and fixed the 11.2 issue and will now close this as WONTFIX.

Update released for: kernel-debug, kernel-debug-base, kernel-debug-base-debuginfo, kernel-debug-debuginfo, kernel-debug-debugsource, kernel-debug-devel, kernel-debug-devel-debuginfo, kernel-default, kernel-default-base, kernel-default-base-debuginfo, kernel-default-debuginfo, kernel-default-debugsource, kernel-default-devel, kernel-default-devel-debuginfo, kernel-desktop, kernel-desktop-base, kernel-desktop-base-debuginfo, kernel-desktop-debuginfo, kernel-desktop-debugsource, kernel-desktop-devel, kernel-desktop-devel-debuginfo, kernel-pae, kernel-pae-base, kernel-pae-base-debuginfo, kernel-pae-debuginfo, kernel-pae-debugsource, kernel-pae-devel, kernel-pae-devel-debuginfo, kernel-source, kernel-source-vanilla, kernel-syms, kernel-trace, kernel-trace-base, kernel-trace-base-debuginfo, kernel-trace-debuginfo, kernel-trace-debugsource, kernel-trace-devel, kernel-trace-devel-debuginfo, kernel-vanilla, kernel-vanilla-base, kernel-vanilla-base-debuginfo, kernel-vanilla-debuginfo, kernel-vanilla-debugsource, kernel-vanilla-devel, kernel-vanilla-devel-debuginfo, kernel-xen, kernel-xen-base, kernel-xen-base-debuginfo, kernel-xen-debuginfo, kernel-xen-debugsource, kernel-xen-devel, kernel-xen-devel-debuginfo, preload-kmp-default, preload-kmp-desktop
Products:
openSUSE 11.2 (debug, i586, x86_64)