> this is cut-n-paste from just now. i ejected a blank disk and reinserted it.
>
> ladd# cat ctl
> inquiry TSSTcorpCD/DVDW SH-S182MSB00 0726 0137PL
> config 85C0 capabilities 0F00 dma 00550004 dmactl 00000000
> ladd# echo dma on>ctl
> echo: write error: media or partition has changed
> ladd# echo dma on>ctl
> echo: write error: media or partition has changed
>
> scuzz is able to identify, though.
bizarre.
this is cut-n-paste from just now, with a blank dvd in the drive:
cpu% cat /dev/sdC1/ctl
inquiry MATSHITADVD-RAM LF-D310 A12608/01/02
config 85C0 capabilities 0F00 dma 00550004 dmactl 00550004
cpu% echo dma on >/dev/sdC1/ctl
cpu%
sure enough, though, if i do it the way you did:
cpu% cd /dev/sdC1
cpu% cat ctl
inquiry MATSHITADVD-RAM LF-D310 A12608/01/02
config 85C0 capabilities 0F00 dma 00550004 dmactl 00550004
cpu% echo dma on >ctl
echo: write error: i/o error
cpu%
that's a different error, but close enough (if the attempt at
rescanning the disk produced an error then you wouldn't
get to the media change).
i see what's going on: your example runs *in* the /dev/sdC1
directory, and every time a lookup happens in that directory
while the size is zero, the version does get bumped:
cpu% ls -q /dev/sdC1
(0000000004301005 263 00) /dev/sdC1/ctl
(0000000004301006 264 00) /dev/sdC1/raw
cpu% ls -q /dev/sdC1
(0000000004301005 273 00) /dev/sdC1/ctl
(0000000004301006 274 00) /dev/sdC1/raw
cpu%
so when you run "echo dma on >ctl", that causes an open of
ctl and then an exec of echo. the exec of echo rescans /dev/sdC1
and the version on everything gets bumped, so by the time
echo does the write, the open ctl is treated as out-of-date.
if i change the path to look in /bin for echo before ., then
working in /dev/sdC1 is okay:
cpu% path=(/bin .)
cpu% cd /dev/sdC1
cpu% cat ctl
inquiry MATSHITADVD-RAM LF-D310 A12608/01/02
config 85C0 capabilities 0F00 dma 00550004 dmactl 00550004
cpu% echo dma on >ctl
cpu%
so it sounds like the problem is that sdinitpart should not
bump the version number if the drive size is zero and the
last time it was called the drive size was zero too.
> i consider this a driver problem. in the ahci driver i'm currently
> working on, if "new" drive has the same serial# as the old drive,
> i don't report a media change.
>
> admittedly, this is a huristic because you could have removed the
> drive, paved it and put it back. but that might fall under the
> "deserves to loose" banner. in any event, the drive can't ever
> say with confidence that all the data is the same as was written.
i think that if you yank the disk and put it back in,
that's a media change and the version should change.
(the same thing happens if you eject a cd and put the
same one back in.)
it would be great if the ducks could be lined up so that
the version number doesn't change on disk reset though,
but as you say that is more of an underlying driver issue.
(in fact, sdmv is the only driver in the distribution with
a "reset" ctl message, so the version-change-on-reset
problem is at the moment specific to sdmv.)
russ
