AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080131151705.4daeffe8@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<narain.ramadass@onstor.com>,<sripal.surendiran@onstor.com>,<brian.deforest@onstor.com>,<tim.gardner@onstor.com>,<jonathan.goldick@onstor.com>,<sudharsan@onstor.com>,<deepak.veliath@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E08058C2D@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 31 Jan 2008 15:17:15 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Narain Ramadass" <narain.ramadass@onstor.com>
Cc: "Sripal Surendiran (HCL)" <sripal.surendiran@onstor.com>, "Brian
 DeForest" <brian.deforest@onstor.com>, "Tim Gardner"
 <tim.gardner@onstor.com>, "Jonathan Goldick" <jonathan.goldick@onstor.com>,
 "Sudharsan Srinivasan" <sudharsan@onstor.com>, "Deepak Veliath"
 <deepak.veliath@onstor.com>
Subject: Re: Bobcat to Cougar migration document for review
Message-ID: <20080131151715.4e5a0857@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E08058C2D@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04EC247B1@onstor-exch02.onstor.net>
	<20080131143705.5d1d2aa0@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E08058C2D@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

On Thu, 31 Jan 2008 14:58:11 -0800 "Narain Ramadass"
<narain.ramadass@onstor.com> wrote:

> Andy,
> 
> PFA the mail from DeepakV regarding the BSD disklabels being read from
> Linux. This is an initial finding and we will be attempting to script
> this to work for both - the old as well as the new CF layout.

OK, I dug out this email, which I don't remember at all for some
reason, and it looks promising.  We only need support the new CF layout
which is at least 3.0.  I don't think it is an unreasonable
requirement that we can only migrate from a 3.X or later release.  3.0
was released close to a year before Cougar will be released, IIRC.  We
only need the /, /var and /onstor/conf partitions so only those need be
created in the DOS partition table.

But if all that is true (the info in Deepak's email), can't we just
copy the BSD partition table to where it belongs and then it should all
just work?  Or am I missing something?  I tried that once
unsuccessfully myself, but most likely I did it wrong.  A CF card
created by a standard OpenBSD system is able to mount just fine,
detecting and using the BSD partition table under the DOS partition
table.

> As for the FTI related content in the document: 
> 
> 1. The migration strategy is assumed to be a variant of "system config
> copy". Our thinking was on the lines of this being included with
> Cougar for sometime and dropped thereafter. "System Config Copy" would
> therefore recognize the BSD disklabels on the secondary flash and copy
> the files appropriately in case a migration were required.
> 
> 2. In general FTI and "system config copy" work independently of each
> other - but are "aware" of each other and share a lot of code - that
> is the purpose of bringing them together in the document.
> 
> HTH,
> Narain.
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Thursday, January 31, 2008 2:37 PM
> To: Sripal Surendiran (HCL)
> Cc: Brian DeForest; Tim Gardner; Jonathan Goldick; Sudharsan
> Srinivasan; Narain Ramadass
> Subject: Re: Bobcat to Cougar migration document for review
> 
> On Thu, 31 Jan 2008 05:46:25 -0800 "Sripal Surendiran (HCL)"
> <sripal.surendiran@onstor.com> wrote:
> 
> > Hi All,
> >  
> > PFA document that contains strategy for migrating from Bobcat to 
> > Cougar system. Please look into the document and let me know your 
> > thoughts. Regards Sripal.
> 
> Page 1
> 
> +  I haven't been able to read a bobcat compact flash in a linux
> system. Have you?
> 
> Page 2
> 
> +  Section 1, Line #11: the directory is the same -- it's the same
> code, after all.
> 
> +  Section 2, Assumptions and dependencies.  I don't agree with a lot
> of these assumptions and dependencies, like #2, #3, #4, #7, and #9.
>    There is no reason why a migration should be dependent on FTI.  FTI
>    can use it or whatever, but it should be modular, separate,
>    preferably something that can be run from a bash prompt or nfxsh
>    prompt.  A shell script would be fine in my opinion.
> 
> 
> I agree with Tim, a proper func-spec document is most likely warranted
> here.
