AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20081016141915.2341fcbd@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<deepak.veliath@onstor.com>,<dl-designreview@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#mh/Mailbox/design review	0	BB375AF679D4A34E9CA8DFA650E2B04E0C0D8754@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 16 Oct 2008 14:19:51 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Deepak Veliath" <deepak.veliath@onstor.com>
Cc: "dl-Design Review" <dl-designreview@onstor.com>
Subject: Re: Functional Spec for Restarting Aborted Mirror Sessions
Message-ID: <20081016141951.2a5de00c@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0C0D8754@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E0C0D86BA@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E0C0D8733@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E0C0D8754@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

This one is complicated enough that I think we should schedule a
meeting to discuss.  Anyone disagree?

On Thu, 16 Oct 2008 14:04:35 -0700 "Deepak Veliath"
<deepak.veliath@onstor.com> wrote:

> Hello Jonathan,
> 1.	Section 5, as you make clear, the key to restarting is to
> know what the target has on disk, basically a checkpoint marker.
> Since we send blocks in order can we just periodically write out the
> last block number know to have hit disk?  A super-block field would
> be easy.  While an implementation note, this would avoid changing the
> cluster DB and that is relevant here.  When all the blocks have been
> received we can just set the number to the last block number in the
> file system so it handles a lot of the cases you have mentioned.
> 
> We issue I/Os to read the blocks on the source in order.  But there
> seems to be no guarantee the I/Os finish and return in that order.  We
> send out blocks to the target as soon as they have been read.  On the
> target again the I/O is issued as they come in over the RMC connection
> but there seems to be no guarantee of ordering.  I realize our current
> IO scheduler might guarantee some sort of ordering, but this could
> change in the future.  The mirroring sub-system shouldn't expect it
> works a certain way unless the IO scheduler exports a mechanism to
> guarantee this ordering.
>     
> 2.	Section 6, I'm not sure that the restart command adds a lot,
> avoiding the creation of a new snapshot is the only clear addition
> over mirror start and that doesn't seem worth creating a new command
> verb.
> 
> Since creating a new snapshot consumes some amount of space (and will
> mean space can be allocated as the FS is modified), I felt a "restart"
> only command would allow a previously aborted mirror to run through to
> completion without potentially consuming space in the FS.
>  
> 3.	Section 6, mirror start MIRRORNAME [skiprestart] To date we
> have not used whole words for command options in the shell, but
> instead use things like -a, -b, etc.  Other than testing, why would a
> customer ever want to skip a restart?  While a large transfer can
> happen at any point, the real problem here is baseline transfers so
> if the target is garbage in some way we can just start over by
> detecting that, rather than having the administrator try to figure it
> out.  This also reduces the test cases and the need to change the GUI
> or the CLI. 
> 
> I see a lot of "force" options in the existing mirroring commands --
> they were the basis for this choice.  I'll change it to "-s".  As to
> the need for such an option, I felt a mechanism to bypass the whole
> restart logic and being able to fall-back on to the traditional logic
> might be desired by an administrator.  The baseline transfer has
> nothing to do with this option and can be completed successfully with
> or without this option.
> 
> Thank you,
> veliath
>  
> 
>  
> 
>  
> 
> ________________________________
> 
> From: Deepak Veliath 
> Sent: Thursday, October 16, 2008 12:03 PM
> To: dl-Design Review
> Subject: Functional Spec for Restarting Aborted Mirror Sessions
> 
>  
> 
> \\mightydog\software\Kegg\Functional
> Specs\RestartAbortedMirrorSessionsFuncSpec.doc
> <file:///\\mightydog\software\Kegg\Functional%20Specs\RestartAbortedMirr
> orSessionsFuncSpec.doc> 
> 
