AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20090114111052.32e3d590@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:exch1.onstor.net
NSV:
SSH:
R:<maxim.kozlovsky@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#mh/Mailbox/design review	0	2779531E7C760D4491C96305019FEEB51763B781AE@exch1.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 14 Jan 2009 11:11:45 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: Maxim Kozlovsky <maxim.kozlovsky@onstor.com>
Subject: Re: TuxRx Functional Spec
Message-ID: <20090114111145.760306eb@ripper.onstor.net>
In-Reply-To: <2779531E7C760D4491C96305019FEEB51763B781AE@exch1.onstor.net>
References: <20090106152711.76b59d5d@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB5176334C548@exch1.onstor.net>
	<20090113201411.4080c3aa@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB51763B781A5@exch1.onstor.net>
	<2779531E7C760D4491C96305019FEEB51763B781AE@exch1.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 Wed, 14 Jan 2009 10:58:43 -0800 Maxim Kozlovsky
<maxim.kozlovsky@onstor.com> wrote:

> If you are not going to provide some sort of rcon, how you are going
> to support the interactive debugging after the crash? Logging into
> txrx and running user space commands will not work after the crash.

What "interactive debugging after a crash" are you referring to?

> >-----Original Message-----
> >From: Maxim Kozlovsky
> >Sent: Wednesday, January 14, 2009 10:51 AM
> >To: Andy Sharp; Jonathan Goldick
> >Cc: dl-Design Review
> >Subject: RE: TuxRx Functional Spec
> >
> >I think it is not acceptable to not provide kernel core dumps.
> >
> >>-----Original Message-----
> >>From: Andy Sharp
> >>Sent: Tuesday, January 13, 2009 8:14 PM
> >>To: Jonathan Goldick
> >>Cc: dl-Design Review
> >>Subject: Re: TuxRx Functional Spec
> >>
> >>New versions available here:
> >>
> >>http://intranet.onstor.net/md/Software/Kegg/Functional%20Specs/tuxrx_func_
> >s
> >>pec.pdf
> >>
> >>http://intranet.onstor.net/md/Software/Kegg/Functional%20Specs/tuxrx_func_
> >s
> >>pec.doc
> >>
> >>Comments not covered in the changes replied to inline
> >>(section 5. c,d,f):
> >>
> >>
> >>
> >>On Wed, 7 Jan 2009 11:47:32 -0800 Jonathan Goldick
> >><jonathan.goldick@onstor.com> wrote:
> >>
> >>> 1. Section 5:
> >>>   a. How will memory change for the ACPU?  Will we have just as
> >>> much available for NFS/CIFS as before?  Will we get more memory
> >>> back because of increased efficiencies or lose some due to new
> >>> overheads?
> >>
> >>> b. Will core dumps work the same way since now there will also be
> >>> user-space processes that didn't exist in EEE that could also
> >>> crash? Will they still go to the management volume and have the
> >>> same names as before?  Analyzing a Linux core will have a new
> >>> procedure.
> >>
> >>> c. Will the system boot faster/slower/same?
> >>
> >>I would say about the same.  It seems to me that the cumulative time
> >>for TXRX image to load and for it to become "ready" is about 20
> >>seconds (for production build) and I expect it to be about that for
> >>TuxRx.
> >>
> >>> d. Will we still need to use wd_kick for watchdog support in the
> >>> ACPU or is Linux handling that in a new way?
> >>
> >>Really an implementation detail that hasn't been decided yet.
> >>Probably will be based on what gives the best functionality.
> >>
> >>> e. Does the ACPU performance profile change now that you are
> >>> probably using the default Linux scheduler instead of our current
> >>> model of polling routines with a maximum number of work items
> >>> before returning to the main loop.  This question edges on design
> >>> but has an external manifestation of performance.
> >>
> >>> f. In general, this section has too little detail about what
> >>> workflows will change, especially around diagnostics and support.
> >>
> >>Agreed.  I will try to be watchful to update the document as they
> >>occur to me.
> >>
> >>> 2. Section 6
> >>> a. I suspect that the UI for rcon and the associated console
> >>> commands will likely change. This will in turn impact diagnostic
> >>> procedures we use in the field. For example, the 'eee' command is
> >>> how we look at memory utilization and that will be completely
> >>> different in Linux. You should say something about these
> >>> commands, especially ones like 'req trace on' which is the debug
> >>> ACPU command that traces the CIFS/NFS states.
> >>> b. Do we have to login to yet another root account, this time for
> >>> the TXRX?
> >>>
> >>> 3. Section 10, you can probably get a better estimate by how much
> >>> head room is available on the ACPU and FP processors today at
> >>> maximum spec load.  Since your changes will not be increasing
> >>> their performance in the first incarnation, which is a pretty good
> >>> estimator assuming that you are not also changing the useable
> >>> memory and scheduler for the ACPU.
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Andy Sharp
> >>> Sent: Tuesday, January 06, 2009 3:27 PM
> >>> To: dl-Design Review
> >>> Subject: RFC: TuxRx Functional Spec
> >>>
> >>> Please review and comment on the TuxRx Project Functional Spec:
> >>>
> >>> http://ripper.onstor.net/eng/tuxrx/tuxrx_func_spec.pdf
> >>>
> >>> http://ripper.onstor.net/eng/tuxrx/tuxrx_func_spec.pages
> >>>
> >>> Thanks,
> >>>
> >>> a
