X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C8809A.6A6989F2@onstor-exch02.onstor.net>; Fri, 7 Mar 2008 14:30:07 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: please review 28211
Date: Fri, 7 Mar 2008 14:30:07 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E056C9448@onstor-exch02.onstor.net>
In-Reply-To: <20080307125321.320c14df@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: please review 28211
Thread-Index: AciAlUms5zifk8HXSY6dxqHa82UQpwABGrbg
From: "Larry Scheer" <larry.scheer@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>

I think large paths and NFS mounts would be corner cases. I think fstabs
with nfs mounts will be highly unlikely in the field. They probably only
occur in house. I think what you have will probably work for 95-99% of
all uses. I just brought up so that there is some awareness. Perhaps a
comment in the code is warranted? I leave it up to you...

-----Original Message-----
From: Andy Sharp=20
Sent: Friday, March 07, 2008 12:53 PM
To: Larry Scheer
Subject: Re: please review 28211

On Fri, 7 Mar 2008 11:47:58 -0800 "Larry Scheer"
<larry.scheer@onstor.com> wrote:

> nfx-tree/code/ssc-genlib/fs-openbsd.c
>=20
>      looks good
>=20
> nfx-tree/code/ssc-initial-config/initial-config.c
>=20
>      Lines 1872 - 1880 Looks like these should be moved below line
> 1894. Line 1889 - 1890 Looks like these should be moved above line
> 1895. After moving these lines around the order of make writable and
>      mount secondary remain the same as the original version. If your
>      intent was to swap the order then more window dressing is needed.

fixed.  duh.  please re-review that part.

> nfx-tree/code/ssc-zebra/fs-vector.c
>=20
>      Line 157, is 79 characters large enough for the device and mount
>      dir? Maybe... But what if there is a long NFS path in an NFS
>      mount? This might be fine for a while... dunno.

Well, it now cuts it off at 80, whereas before it would just overflow
the buffer and scrog the stack.  Do we need to care about NFS entries?
It was large enough for the ones on my test bobcat, but that isn't
necessarity the test.

If it were to truncate large entries like NFS entries, would that harm
anything?  I ask because I didn't really consider that when I changed
the code.

> -----Original Message-----
> From: Andy Sharp=20
> Sent: Thursday, March 06, 2008 8:40 PM
> To: Larry Scheer
> Subject: please review 28211
>=20
> Change 28211 by andys@ripper on 2008/03/06 15:39:52 *pending*
>=20
>         TED00022323 - FTI Doesn't copy config from secondary flash
>        =20
>         FTI code not properly remounting root read-write, so
>         config files not copied.
>        =20
>         Wrong file included in ssc-genlib/fs-linux.c causing
>         Linux config files to be copied on both Linux and
>         OpenBSD systems.
>        =20
>         Found and fixed potential overflow problem with fscanf
>         and fgets in make_secondary_fstabs which was causing
>         core dumps when fstab had unusual lines.
>        =20
>         reviewed by
>=20
> Affected files ...
>=20
> ... //depot/dev/nfx-tree/code/ssc-genlib/fs-openbsd.c#5 edit
> ... //depot/dev/nfx-tree/code/ssc-initial-config/initial-config.c#5
> edit ... //depot/dev/nfx-tree/code/ssc-zebra/fs-vector.c#2 edit
>=20
