Re: fatal flaw in diskcheckd...
On Wed, 18 Jul 2001, Matthew Jacob wrote: So, I took a SCSi disk away. Diskcheckd started complaining. However, a camcontrol rescan couldn't make the disk go away until I killed off diskcheckd, which then closed the disk, allowing the rescan to remove it. Bad. Bad. Bad. This may also have caused your disklabel problems. The old label doesn't go away until all minors on the device are closed, at least when you clobber the label using the dd hack. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fatal flaw in diskcheckd...
On Thu, 19 Jul 2001 [EMAIL PROTECTED] wrote: So, I took a SCSi disk away. Diskcheckd started complaining. However, a camcontrol rescan couldn't make the disk go away until I killed off diskcheckd, which then closed the disk, allowing the rescan to remove it. Bad. Bad. Bad. This may also have caused your disklabel problems. The old label doesn't go away until all minors on the device are closed, at least when you clobber the label using the dd hack. In some situations it would be very useful to be able to tell the kernel forget all you ever knew about disklabel X. Any good mechanisms to do this today (other than reboot)? Nothing good, by the DIOCSYNCSLICEINFO ioctl tells the kernel to reread all the slice and label info from the disk like it would after a reboot. It is used by libdisk (and thus mainly by sysinstall). It has a force flag that makes it attempt to work when minors other than the one needed to do the ioctl (the one for the whole disk) are open. I don't really trust it when it is forced, but libdisk always forces it. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fatal flaw in diskcheckd...
On Wed, 18 Jul 2001, Matthew Jacob wrote: So, I took a SCSi disk away. Diskcheckd started complaining. However, a camcontrol rescan couldn't make the disk go away until I killed off diskcheckd, which then closed the disk, allowing the rescan to remove it. Bad. Bad. Bad. This may also have caused your disklabel problems. The old label doesn't go away until all minors on the device are closed, at least when you clobber the label using the dd hack. Ummm. maybe... I think on that system I had disabled disckcheckd, but it's an excellent suggestion for me to check. With respect to diskcheckd, which in general is a neat tool to have around, I think it might be better if it did: open seek read close rather than leaving a disk open anyway. The difference between problems with an open as opposed to problems with a read are worth noting anyway. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fatal flaw in diskcheckd...
* Matthew Jacob [EMAIL PROTECTED] [010718 16:33] wrote: So, I took a SCSi disk away. Diskcheckd started complaining. However, a camcontrol rescan couldn't make the disk go away until I killed off diskcheckd, which then closed the disk, allowing the rescan to remove it. Bad. Bad. Bad. ev/da4 Jul 18 14:31:15 diskcheckd[202]: error reading 512 bytes from sector 908502 on /dev/da4 Jul 18 14:31:15 diskcheckd[202]: error reading 512 bytes from sector 908505 on /dev/da4 Jul 18 14:31:15 diskcheckd[202]: error reading 512 bytes from sector 908506 on /dev/da4 Jul 18 14:31:15 diskcheckd[202]: error reading 512 bytes from sector 908513 on /dev/da4 Jul 18 14:31:51 diskcheckd[202]: error reading 512 bytes from sector 908629 on /dev/da4 Jul 18 14:31:51 diskcheckd[202]: error reading 512 bytes from sector 908636 on /dev/da4 (da4:isp3:0:5:0): Synchronize cache failed, status == 0x4a, scsi status == 0x0 (da4:isp3:0:5:0): removing device entry Is diskcheckd still on by default? If so, can whomever enabled it turn it off? If not I'll be 'fixing' this oversight this afternoon. thanks, -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fatal flaw in diskcheckd...
Still on by default. On Wed, 18 Jul 2001, Alfred Perlstein wrote: * Matthew Jacob [EMAIL PROTECTED] [010718 16:33] wrote: So, I took a SCSi disk away. Diskcheckd started complaining. However, a camcontrol rescan couldn't make the disk go away until I killed off diskcheckd, which then closed the disk, allowing the rescan to remove it. Bad. Bad. Bad. ev/da4 Jul 18 14:31:15 diskcheckd[202]: error reading 512 bytes from sector 908502 on /dev/da4 Jul 18 14:31:15 diskcheckd[202]: error reading 512 bytes from sector 908505 on /dev/da4 Jul 18 14:31:15 diskcheckd[202]: error reading 512 bytes from sector 908506 on /dev/da4 Jul 18 14:31:15 diskcheckd[202]: error reading 512 bytes from sector 908513 on /dev/da4 Jul 18 14:31:51 diskcheckd[202]: error reading 512 bytes from sector 908629 on /dev/da4 Jul 18 14:31:51 diskcheckd[202]: error reading 512 bytes from sector 908636 on /dev/da4 (da4:isp3:0:5:0): Synchronize cache failed, status == 0x4a, scsi status == 0x0 (da4:isp3:0:5:0): removing device entry Is diskcheckd still on by default? If so, can whomever enabled it turn it off? If not I'll be 'fixing' this oversight this afternoon. thanks, -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fatal flaw in diskcheckd...
* Matthew Jacob [EMAIL PROTECTED] [010718 16:56] wrote: Still on by default. In my queue then. -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
