From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: erik quanstrom Date: Fri, 4 May 2007 23:37:11 -0400 To: 9fans@cse.psu.edu Subject: Re: [9fans] devsd & media changed errors In-Reply-To: <20070505031450.5A86A1E8C2B@holo.morphisms.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 5a7a067c-ead2-11e9-9d60-3106f5b1d025 >> 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