From: Pat LaVarre <p.lavarre@ieee.org>
To: Jens Axboe <axboe@suse.de>
Cc: linux-scsi@vger.kernel.org
Subject: Re: open write failure not predicted by blockdev getro
Date: 14 Jul 2004 18:00:28 -0600 [thread overview]
Message-ID: <1089849628.3736.48.camel@patibmrh9> (raw)
In-Reply-To: <20040714053638.GG3055@suse.de>
> > inserting a read-only DVD disc into a USB drive, ...
> > the paradoxical contradiction:
> > ...
> > $ sudo blockdev --getro /dev/scd0
> > 0
> > $ sudo dd of=/dev/scd0 bs=64K count=1 if=/dev/zero
> > dd: opening `/dev/scd0': Read-only file system
> > $
> ...
> does interest me, ...
Excellent, hi.
> please see if you can track this problem down.
printk tells me,
We call set_disk_ro of drivers/block/genhd.c only once per device plug
in, not once per disc insert.
Logically therefore, given a mixed collection of rewritable and
read-only discs, our guessing blockdev --getro 1 at plug in will prevent
writes of rewritable discs, and our guessing blockdev --getro 0 at plug
in will allow writes of read-only discs.
We necessarily lose both ways.
Do we care?
May we say that blockdev --setrw --setro --getro is a facility for
write-protecting DVD/ CD devices, not DVD/ CD discs, and take on the job
of guessing which devices don't want blanket write protection?
Or do we learn to refresh set_disk_ro once per disc insert?
We can decide in light of the drivers/scsi/sd.c precedent. I see there
a comment telling me we call set_disk_ro once per disc insert:
--- http://lxr.linux.no/source/drivers/scsi/sd.c?v=2.6.5#L1109
...
* read write protect setting, if possible - called only in sd_revalidate_disk()
...
---
Pat LaVarre
P.S. Newbie, me I haven't yet found the lines of cdrom.ko code we run
only once per disc insert.
The following patch ain't it, at least not yet. dmesg tells me this
source line executes indefinitely often while I have a USB DVD disc
(specifically an Iomega RRD disc) present. Even with PATAPI alone
connected, still it ran more often than the count of discs present.
diff -urp linux-2.6.8-rc1/drivers/cdrom/cdrom.c linux-2.6.8-rc1-pel/drivers/cdrom/cdrom.c
--- linux-2.6.8-rc1/drivers/cdrom/cdrom.c 2004-07-13 08:26:02.000000000 -0600
+++ linux-2.6.8-rc1-pel/drivers/cdrom/cdrom.c 2004-07-14 17:46:24.013859464 -0600
@@ -1297,6 +1297,7 @@ int media_changed(struct cdrom_device_in
return ret;
/* changed since last call? */
if (cdi->ops->media_changed(cdi, CDSL_CURRENT)) {
+printk("PEL: could refresh set_disk_ro\n");
cdi->mc_flags = 0x3; /* set bit on both queues */
ret |= 1;
}
prev parent reply other threads:[~2004-07-15 0:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-13 21:38 open write failure not predicted by blockdev getro Pat LaVarre
2004-07-14 5:36 ` Jens Axboe
2004-07-15 0:00 ` Pat LaVarre [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1089849628.3736.48.camel@patibmrh9 \
--to=p.lavarre@ieee.org \
--cc=axboe@suse.de \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox