[cgl_discussion] RE: [cgl_specs] Questions about the usage model of Block device removal

Gross, Mark mark.gross at intel.com
Fri Mar 25 07:16:47 PST 2005



>-----Original Message-----
>From: Zhao, Forrest
>Sent: Thursday, March 24, 2005 7:05 PM
>To: Gross, Mark; 'cgl_discussion at osdl.org'; 'cgl_specs at groups.osdl.org'
>Cc: Fu, Michael; 'sdake at mvista.com'
>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




More information about the cgl_discussion mailing list