AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080707163343.0333f6a9@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<ian.brown@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	635F364E-CF90-4292-8EC4-C13F7326F0A8@onstor.com
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 7 Jul 2008 16:34:22 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: Ian Brown <ian.brown@onstor.com>
Subject: Re: review for change list 29789
Message-ID: <20080707163422.69969fe1@ripper.onstor.net>
In-Reply-To: <635F364E-CF90-4292-8EC4-C13F7326F0A8@onstor.com>
References: <635F364E-CF90-4292-8EC4-C13F7326F0A8@onstor.com>
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 Mon, 30 Jun 2008 18:51:48 -0700 Ian Brown <ian.brown@onstor.com>
wrote:

> emrscron:1227 - don't do the change you propose, instead add the  
> following comment:
> 
> # We unzip then re-zip this file as we roll it because it
> drastically reduces
> # it's size.  Every 3 minutes we cat a gzipped set of stats onto the  
> day's log
> # file however, the gzip algorithm isn't able to take advantage of the
> # intra-stat-reading text similarities when it zips only one entry
> at a time.
> # So, when we roll it we re-zip it, then the gzip algorithm works  
> great because
> # much of the text for each 3 minute stat output is the same.

fixed

> support.sh:13-24 - these lines should go just before line 261.  The  
> reason is that the usage() function which has the help text should
> go as near the top of the file as possible, everything that is
> before this should be required to be before this.  these lines are
> not needed till 261.

usage is just a function, it's usually helpful to group the functions
together, so I moved them to after usage.  these might be useful for
setting some variable some day some time some universe

> support.sh:283 - a comment with the arguments would be helpful (see  
> next question).

fixed

> support.sh:285 - why are you using $2 instead of $1?

wtf?  fixed.
this was this way on my filer as well, so i will fix it there and
continue to test it.  can't believe that somehow snuck through.
obviously at one time gkill took two arguments.

> support.sh:314,329 - the '{' should go on it's own line.  (the
> reason I mention this is because a vim feature that I use... :| )

fixed

> support.sh:319 - 'racy'   (race)?

standard comment for code that is subject to theoretical race
conditions ... this code is "racy"

> support.sh:4142 - why was this commented out?

this is highly buggy, has a silent tendency to kill things it shouldn't
and not kill things it should and is hard to get right and universal
for both OSes.  it doesn't seem to be needed anymore with a reliable
timeout mechanism that slaughters everything.  of course i didn't try
to see what happens if i hit CTRL-Z from nfxsh.

> support.sh:3442 - sweet, there's a mktemp command in unix!  I wish I  
> knew that when I was writing lines 151 and 152.
> 
> support.sh:3443 & 3445 - why the mount and then re-mount right away?

first mount is to mount the root fs of the secondary flash and read
it's fstab file, and then umount that, then mount (and later
umount) everything according to the secondary fstab file.

> 
> - Ian