In message <1112015844.1022.44.camel_at_localhost>, Vladimir Grebenschikov writes: >В пн, 28/03/2005 в 15:04 +0200, Bernd Walter пишет: >> On Mon, Mar 28, 2005 at 04:58:31PM +0400, Vladimir Grebenschikov wrote: >> > ? ??, 28/03/2005 ? 14:13 +0200, Poul-Henning Kamp ?????: >> > > In message <20050328114633.GZ14532_at_cicely12.cicely.de>, Bernd Walter writes: >> > > >> > > >> camcontrol detach da0; camcontrol rescan all >> > > >> helps, but, it should be much better if it will be issued automatically. >> > > > >> > > >Yes - GEOM seems to ignore media change signals from drives. >> > > >I've added PHK to the recipient list - maybe he has an idea about this >> > > >problem. >> > > >> > > No, GEOM doesn't ignore any such thing, because as far as I know >> > > GEOM doesn't get any such thing to ignore in the first place. >> > >> > So, let's imagine following situation: >> > >> > We get SCSI BUS with removable da device. >> > device detected as da0 and not mounted. >> > Device disconnected from SCSI bus. >> > And finally, another device with different geometry connected with same >> > SCIS ID. >> >> This ist not a *media* exchange - this is a *device* and in >> this case even a scbus exchange. > >Ok, so my case is media exchange, not device exchange. >How it is supposed to work in this case ? That's a very good question. The original intent in GEOM was that the geom instance would represent the media while the drive (if separate for the media) would have another access mechanism. Driver support for this is not really meaterialized and therefore the model now is that when the media is ejected the geom device is removed and a new one created right away, even if a new media is not inserted right away. This works with the broken-by-design CDrom ioctls etc. What is missing is to tickle GEOM when the media is inserted so that the tasting takes place. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk_at_FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.Received on Mon Mar 28 2005 - 11:32:49 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:30 UTC