[9fans] devsd & media changed errors

[9fans] devsd & media changed errors

[erik quanstrom]

when a disk or a cdrom reports that it has 0 sectors
devsd won't let you write to the control file.  it gives

	write error: media or partition has changed.

this is because sdinitpart increments the partition vers
each time it is called and it's called in many places when
the number of sectors is zero.

there are a couple of senerios where this is a pain.
first, if you have a blank cdrom in the tray, you can't

	echo dma on>/dev/sdXX/ctl

worse, if i have a drive that sometimes needs to be reset
manually.  (some sata drives have loopy firmware.)  i can't

	echo reset>/dev/sdE5/ctl

to fix it.  (one could abuse /dev/sdctl to do this, but then
you've reinvented the problem of figuring out which
device is the intended target of the request.)

am i missing something here or is this a real devsd
problem?  without knowing a whole lot about devsd,
i would think that the devsd should allow writes to
the control file even when sectors == 0.  perhaps
letting -1 sectors be the sentinal value would be enough.

- erik

Re: [9fans] devsd & media changed errors

[Russ Cox]

> when a disk or a cdrom reports that it has 0 sectors
> devsd won't let you write to the control file.  it gives

this is not true.  what is true is that if you open
the ctl file and then the media changes, then you
are required to reopen the ctl file in order to start
using it.  this is true of all the disk files.

> first, if you have a blank cdrom in the tray, you can't
> 
> 	echo dma on>/dev/sdXX/ctl

i can't test this, but i don't believe this is true.
(see above.)

> worse, if i have a drive that sometimes needs to be reset
> manually.  (some sata drives have loopy firmware.)  i can't
> 
> 	echo reset>/dev/sdE5/ctl
> 
> to fix it. 

i *know* this isn't true.  i do this all the time (personally i think
the sdmv driver is not quite driving the disks right).

since ctl is used for things like partitioning the disk, i think
it is reasonable that if the disk has changed since you 
opened the file, then you should need to reopen it.

i do find it annoying that when i reset a disk this way,
it appears to the sd framework as if the underlying
disk has changed, so all the partitions go away, and
all the open file descriptors get poisoned, but i'm not
sure this is incorrect behavior.  the media did sort of
change -- it went away and came back.

in venti i have worked around this by reloading the
partition table and then reopening the file descriptors,
but that's admittedly a pain.  

russ

Re: [9fans] devsd & media changed errors

[erik quanstrom]

>> when a disk or a cdrom reports that it has 0 sectors
>> devsd won't let you write to the control file.  it gives
>
>this is not true.  what is true is that if you open
>the ctl file and then the media changes, then you
>are required to reopen the ctl file in order to start
>using it.  this is true of all the disk files.

russ, you are not correct.  i just retried using the pc/sdata
driver.

> first, if you have a blank cdrom in the tray, you can't
> 
> 	echo dma on>/dev/sdXX/ctl
>i can't test this, but i don't believe this is true.
>(see above.)

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.

>> worse, if i have a drive that sometimes needs to be reset
>> manually.  (some sata drives have loopy firmware.)  i can't
>> 
>> 	echo reset>/dev/sdE5/ctl
>> 
>> to fix it. 

>i *know* this isn't true.  i do this all the time (personally i think
>the sdmv driver is not quite driving the disks right).

i wasn't using the sdmv50xx driver.  i have had similar results with
the sdata driver and a new driver that i'm working on.

> since ctl is used for things like partitioning the disk, i think
> it is reasonable that if the disk has changed since you 
> opened the file, then you should need to reopen it.

this sounds reasonable to me.

> i do find it annoying that when i reset a disk this way,
> it appears to the sd framework as if the underlying
> disk has changed, so all the partitions go away, and
> all the open file descriptors get poisoned, but i'm not
> sure this is incorrect behavior.  the media did sort of
> change -- it went away and came back.

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 becaus 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.

- erik

Re: [9fans] devsd & media changed errors

[Russ Cox]

> 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