Cool, must try that to see if the issues are mitigated, the issues are reported on Distributions in default configurations. The panics I have seen have been access violations due to bugs in the filesystem layers dealing with some of the inconsistencies. No different to mounting a corrupted filesystem. Sometimes the filesystem driver can see the punch coming, I contend that sometimes it does not... Since it is a design goal to survive, then I better be putting up traces and submitting fs patches, rather than b*&^ing eh? I'd still feel more comfortable having the RAID management GUIs put up a popup box warning the user that what he is about to do to a device currently in-use is dangerous. Reporting a refcount (which covers both filesystem and direct i/o as used by database engines) would help. Sincerely -- Mark Salyzyn -----Original Message----- From: James Bottomley [mailto:James.Bottomley@xxxxxxxxxxxx] Sent: Thursday, August 11, 2005 12:08 PM To: Salyzyn, Mark Cc: Harald Seipp; SCSI Mailing List Subject: RE: remove-single-device removes mounted HDDs (kernel 2.6) On Thu, 2005-08-11 at 11:51 -0400, Salyzyn, Mark wrote: > The problem with pushing this policy to the user is that software > applications have no means to determine that a device is currently > in-use. For instance, the net result of pulling a device on a mounted > filesystem is an eventual kernel panic. The kernel only panics if you told it to with the mount option errors=panic (or if you have errors=panic set in the superblock flags). For file systems on removable devices you shouldn't be telling it to panic on error, you should be telling it to continue or remount-ro. If you do this then you can happily yank the undelying device on a mounted fs, which was one of the design goals of the 2.6 SCSI state model and refcounting reworks. James - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
