Re: Patch to fix panic when detaching a mounted md device
In message [EMAIL PROTECTED] Dima Dorfman writes: : Right now, if you try to detach an md device that's currently mounted, : you will get a panic (maybe not immedietely, but it will come, esp. if : you ever try to use that mountpoint again). I'm pretty sure this is a : known problem, with the solution--or workaround--being, "then don't do : that." The problem is, someone will invariably do it. The fix is to : make md complain if you try to detach a device that's currently : opened. Below is a patch that implements this by keeping track of the : number of times a device has been opened. I'd like to see the kernel deal with this in a more graceful way. The kernel will crash if you have a ata flash mounted and you eject the card... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to fix panic when detaching a mounted md device
In message [EMAIL PROTECTED], Dima Dorfman write s: Hello -hackers Right now, if you try to detach an md device that's currently mounted, you will get a panic (maybe not immedietely, but it will come, esp. This is intentional, I want md(4) to mimic the behaviour of "real" disks as closely as possible, including the fact that it may disappear without notice or caution. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to fix panic when detaching a mounted md device
In message 5663.984480931@critter Poul-Henning Kamp writes: : In message [EMAIL PROTECTED], Dima Dorfman write : s: : Hello -hackers : : Right now, if you try to detach an md device that's currently mounted, : you will get a panic (maybe not immedietely, but it will come, esp. : : This is intentional, I want md(4) to mimic the behaviour of "real" : disks as closely as possible, including the fact that it may disappear : without notice or caution. We should then fix the rest of the system to deal with disks that disappear without notice. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to fix panic when detaching a mounted md device
It seems Warner Losh wrote: In message 8773.984501263@critter Poul-Henning Kamp writes: : We should then fix the rest of the system to deal with disks that : disappear without notice. : : That was the point yes :-) Cool. When this happens, the forgetful ata flash ejectors of the world will be happy :-) The next commit to the ATA driver will take care off this, either by the user doing 'atacontrol detach dev' or by the timeout code discovering that a divice went missing and proberly fail all the outstanding bio requests.. This all needed the patch to subr_disk.c that I made earlier today, but now we can actually do it, however some of the cleanup action should be done by the higher levels and not by the device driver... -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to fix panic when detaching a mounted md device
In message [EMAIL PROTECTED] Soren Schmidt writes: : This all needed the patch to subr_disk.c that I made earlier today, : but now we can actually do it, however some of the cleanup action : should be done by the higher levels and not by the device driver... Most of the crashes I've seen are in the higher levels... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to fix panic when detaching a mounted md device
It seems Warner Losh wrote: In message [EMAIL PROTECTED] Soren Schmidt writes: : This all needed the patch to subr_disk.c that I made earlier today, : but now we can actually do it, however some of the cleanup action : should be done by the higher levels and not by the device driver... Most of the crashes I've seen are in the higher levels... Where ? I havn't seen any here for quite some time... -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to fix panic when detaching a mounted md device
In message [EMAIL PROTECTED] Soren Schmidt writes: : It seems Warner Losh wrote: : In message [EMAIL PROTECTED] Soren Schmidt writes: : : This all needed the patch to subr_disk.c that I made earlier today, : : but now we can actually do it, however some of the cleanup action : : should be done by the higher levels and not by the device driver... : : Most of the crashes I've seen are in the higher levels... : : Where ? I havn't seen any here for quite some time... The ones I've been seeing on "eject ata when mounted on /foo" are in the vm code or file system code. I'll try it again after your changes to see where we're at. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to fix panic when detaching a mounted md device
On 13-Mar-01 Warner Losh wrote: In message 5663.984480931@critter Poul-Henning Kamp writes: : In message [EMAIL PROTECTED], Dima Dorfman : write : s: : Hello -hackers : : Right now, if you try to detach an md device that's currently mounted, : you will get a panic (maybe not immedietely, but it will come, esp. : : This is intentional, I want md(4) to mimic the behaviour of "real" : disks as closely as possible, including the fact that it may disappear : without notice or caution. We should then fix the rest of the system to deal with disks that disappear without notice. At the very least the md code should propagate an error back up to the top level and not panic. Warner -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
