RE: [cgl_specs] Questions about the usage model of Block device removal
"Gross, Mark" <[email protected]> Thu, 24 Mar 2005 08:56:06 -0800
| Newsgroups | gmane.linux.kernel.carrier-grade |
|---|---|
| Message-ID | <F760B14C9561B941B89469F59BA3A8470971F381@orsmsx401.amr.corp.intel.com> |
>-----Original Message----- >From: Zhao, Forrest [mailto:[email protected]] >Sent: Wednesday, March 23, 2005 9:49 PM >To: [email protected]; [email protected] >Cc: Fu, Michael; [email protected] >Subject: [cgl_specs] Questions about the usage model of Block device removal > >Hi, list > >The requirement of Block Device Removal is described as follows: > >The Linux kernel should allow removal of a block device while it is in >use without degrading reliability of the system. The block device shall >be removable even if in use by an open file (fdisk /dev/sda), a raid >volume, or a filesystem or multiples thereof. > >The first question is: Does this requirement include "surprise removal"? >That is, when the block device is surprise-removed, we should guarantee >the reliability of system. > It would be cool trick to make have such a thing work. I'd consider making that a requirement until the details on why it may not be possible come out. >My second question is: what's the purpose of removing a block device in >use? Or who would remove a block device in use for what purpose? If it's >for displacement, then the new disk will not contain the data on the >original disk; if it's for maintenance, the removed disk will be back at >a later time. Right? Non-stop systems that cannot go down, but have a drive failing. With some zombie process or some other random daemon accessing the device resulting in umount failing to go through the only other alternative is to reboot. This isn't cool for non-stop applications. For such a system to fully work they need to be designed to support volume swapping up at the user space level. However; even with a system so designed there are many ways to block the unmount and removal of the device that can be addressed at the kernel level. I've also seen situations where an os update fails because a block device could not be umounted. From an operations point of view when this happens the work around is an extra reboot prior to the update processing; significantly adding to the amount of time the unit is out of service. >May I know a practical usage case of block device removal from telecom >area? > >Thanks, >Forrest _______________________________________________ cgl_discussion mailing list [email protected] http://lists.osdl.org/mailman/listinfo/cgl_discussion