X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C83D0A.2D94D27F@onstor-exch02.onstor.net>; Wed, 12 Dec 2007 13:58:50 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: Directory and file name cleanup (ex. agile)
Date: Wed, 12 Dec 2007 13:58:45 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E07099F06@onstor-exch02.onstor.net>
In-Reply-To: <20071212134518.5ea6b5d6@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Directory and file name cleanup (ex. agile)
Thread-Index: Acg9CEnPFoCfr3gKQRyE2qrnX5w8EQAAdLHw
References: <20071212130803.1f3558ea@ripper.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E05C73DD7@onstor-exch02.onstor.net> <20071212134518.5ea6b5d6@ripper.onstor.net>
From: "Eric Barrett" <eric.barrett@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>

Curious -- if Linux/Cougar doesn't have crashdump files, what do we get
instead?  They're a fairly important middle step between nada and full
cores.
=20

-----Original Message-----
From: Andy Sharp=20
Sent: Wednesday, December 12, 2007 1:45 PM
To: Sandrine Boulanger
Cc: dl-designreview
Subject: Re: Directory and file name cleanup (ex. agile)

On Wed, 12 Dec 2007 13:16:38 -0800 "Sandrine Boulanger"
<sandrine.boulanger@onstor.com> wrote:

> =20
>=20
> -----Original Message-----
> From: Andy Sharp=20
> Sent: Wednesday, December 12, 2007 1:08 PM
> To: dl-designreview
> Subject: Directory and file name cleanup (ex. agile)
>=20
> =20
>=20
> I have prepared a changelist that cleans up the use of the word
> 'agile'
>=20
> in file and directory names, and also removes /usr/local/agile from
> our
>=20
> software.  Here are the details:
>=20
> =20
>=20
> 1. /usr/local/agile as a directory has not existed now for several
>=20
> releases, so it's time to eradicate it.  Change all references to that
>=20
> directory to /onstor where the files really live.
>=20
> =20
>=20
> 2. agile.conf is a dead file, remove references to it and remove it
>=20
> from the build.
>=20
> =20
>=20
> 3. /var/agile will be split into two different
> directories: /var/onstor
>=20
> for trace files and core dumps (although there is some claim core
> dumps
>=20
> go in /var/run anyway);=20
>=20
> [Sandrine] yes, all deamons cores go to /var/run (except nfxsh, which
> cores wherever it's run from)

Fair enough.  No reason for that to change, and in addition I believe it
is already the same for Cougar/Linux.

Eric Barnett mentioned BSD kernel crash dumps going into /var/crash.
That will not be changed as I believe that is the standard place
for that in the BSD operating system.  Linux/Cougar will not have kernel
crash dump files.

> and /var/log/onstor for log files, including the
>=20
> elog messages file, which will now be /var/log/onstor/messages.  This
> is
>=20
> because /var/agile had become an arbitrary dumping ground without any
>=20
> paradigm or logically intuitive organization.
>=20
> [Sandrine] where would the bsd|linux syslog messages go? Right now we
> have /var/agile/messages* for elogs and /var/log/messages* for bsd
> syslog

Every log file that was in /var/agile will be in heirarchacly (sp?)
moved to /var/log/onstor, so elog will be in /var/log/onstor/messages

> Scope:
>=20
> =20
>=20
> All work necessary to complete this should already be done and
> viewable
>=20
> in the changelist 26643.  There should be no extra changes necessary
> by
>=20
> anyone else, except of course documentation changes.  If you see
>=20
> something is missing, please inform me.
>=20
> =20
>=20
> Timeline:
>=20
> =20
>=20
> This will go into the release following R98 as well as Cougar, so
>=20
> the soonest it will hit customers is in about 3.5 months.  The idea is
>=20
> to get some general use testing of the change in Development, QA and
>=20
> Support to fine tune any rough spots prior to release.  In addition
> the
>=20
> 3 months should and provide plenty of acclimation time.
>=20
> =20
>=20
> Data points:
>=20
> =20
>=20
> Upgrading.  This may require that we obsolete the previous upgrade
>=20
> method (system upgrade), and all upgrades for S-W use the upgrade
>=20
> script.
>=20
> =20
>=20
> Implications for data warehouse?  Should be none, but ....
>=20
