Date: Sat, 25 Jan 1997 10:23:54 -0700 From: Warner Losh <imp@village.org> To: Bruce Evans <bde@zeta.org.au> Cc: scsi@freebsd.org Subject: Re: Question about the scsi sub system. Message-ID: <E0voBpb-0002zM-00@rover.village.org> In-Reply-To: Your message of "Sun, 26 Jan 1997 00:23:33 %2B1100." <199701251323.AAA25410@godzilla.zeta.org.au> References: <199701251323.AAA25410@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199701251323.AAA25410@godzilla.zeta.org.au> Bruce Evans writes: : Mounting a file system keeps the device open. So does swapping. : This stops the sd_close() routine from allowing ejection of the disk. : Other than that, there is nothing special about raw i/o at the device : driver level. Unmounting the file system should break things just as well : as closing the raw device :-). Turning off swapping is not supported :-(. : Ejection isn't allowed even after shutdown. Hmmm, so is there code in the file system to handle scsi disks that need to be spun up? Also, in trying to find the code path through the kernel in question, I was unable to find the cdevsw's table for sd. I'd still like to know where that is being initialized or how bdevsw is being used instead. To recap, if the Jaz drive is spinning when I touch the raw device, then it works and I get a dump. If the drive has gone into power down mode, then I don't. I'm not trying to eject the disk or anything like that, and there is no swapping being done to this device. The file system is mounted the whole time. That is # mount | egrep /jaz /dev/sd1c on /jaz (local) # ls /jaz I hear the drive spin up FreeBSD OpenBSD mips # dump 1f /dev/null /jaz <dumps to /dev/null> # Wait 1/2 hour for drive to spin down. # dump 1f /dev/null /jaz ... sd1(uha0:3:0): NOT READY asc:4,0 sd1(uha0:3:0): Logical unit not ready, cause not reportable DUMP: Cannot open /dev/rsd1c # ls /jaz ls: I/O error # At this point I can't even unmount the disk and remount it. I have to reboot. I've not interested in ejecting the disk, but it won't eject (so sd_close isn't being called). So why would a file system access spin the disk up, while a raw device access wouldn't? I'm confused. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0voBpb-0002zM-00>