RE: [cgl_specs] Questions about the usage model of Block device removal
"Gross, Mark" <[email protected]> Fri, 25 Mar 2005 07:16:47 -0800
| Newsgroups | gmane.linux.kernel.carrier-grade |
|---|---|
| Message-ID | <F760B14C9561B941B89469F59BA3A84709762A98@orsmsx401.amr.corp.intel.com> |
>-----Original Message----- >From: Zhao, Forrest >Sent: Thursday, March 24, 2005 7:05 PM >To: Gross, Mark; '[email protected]'; '[email protected]' >Cc: Fu, Michael; '[email protected]' >Subject: RE: [cgl_specs] Questions about the usage model of Block device removal > >Hi, Mark > >>>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. > >Could you give us more explanation about what "surprise-removal" is used for? >What's the motivation of a "surprise-removal"? I'm making this up, but I don't think it's too far from reality... An admin in a remote compute site controlling some important telco operation, has a requirement to do "live" updates of about 100 ATCA compute blades. These blades all have Serial attached SCSI disks that are hot swappable. The Blades are PXE booted and the disks are used for some data application. Suppose that this application needs updating which requires the disk to be either re-imaged or swapped. Now you have at least two failure modes: 1) operator error could result in pulling the disk out of the wrong blade. 2) If the requested umount operation takes too long, the operator may have instructions to just yank the disk. Up-time is the application. Taking the blade out of service to reboot because of a media upgrade is a bad thing, especially if the system integrator / ISV / NEP has invested a lot of money in a software system that supports this. >Will a new or old disk be used for the replacement? Perhaps, perhaps not. I wouldn't make any assumptions on the replacement media. > >Thanks, >Forrest _______________________________________________ cgl_discussion mailing list [email protected] http://lists.osdl.org/mailman/listinfo/cgl_discussion