X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C71C83.432C00A9@onstor-exch02.onstor.net>; Sun, 10 Dec 2006 09:47:29 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C71C83.432C00A9"
Content-class: urn:content-classes:message
Subject: Clio R2.1 Submittal 8 - RC1 available for testing
Date: Sun, 10 Dec 2006 09:44:27 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E0A10DD@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Clio R2.1 Submittal 8 - RC1 available for testing
thread-index: AccY6/XzKxRmRVxQTvi9NBdZ0ywc+gAADiSQAAbM7tAAAeZNsAARW7xBAJNWRsAABc1NtAABUlQwAAOaxqQAASwOtgAANxJGAASDiMcAAbTpVAAB8VYMAAIqP8wAADyx3AAAKBSgAAhm87oAAAvDIwAY+87f
References: <BB375AF679D4A34E9CA8DFA650E2B04E01AA3DB9@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E013D26E6@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E0133601F@onstor-exch02.onstor.net>
From: "Vikas Saini" <vikas.saini@onstor.com>
To: "dl-Clio" <dl-Clio@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C71C83.432C00A9
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi All,=20
   Clio R2.1 Submittal 8 - RC1 is available for testing. Please load =
this for your Clio testing and continue with your regression. we need to =
load this on our soak systems also so that we have atleast a couple of =
days runtime before we load this on mightydog.

Thanks
Vikas

-----Original Message-----
From: Ken Renshaw
Sent: Sat 12/9/2006 9:49 PM
To: Paul Hammer; Tim Gardner; Vikas Saini; Sandrine Boulanger
Cc: Ken Renshaw
Subject: Clio R2.1 Submittal 8 - RC1 Images Ready for Test - Was: RE: =
longest eek so far !!!
=20
Yep, here's the package info, I'll complete submittal notes tomorrow if =
that's alright:

Changes since submittal 7:

Change 22122 on 2006/12/09 by jobia@jobi:jobi '   leftover changes for =
changes'
Change 22105 on 2006/12/08 by nagendras@nags_r21work 'Fix for TED16641 =
Wildcard chara'
Change 22076 on 2006/12/07 by henryl@henryl-linux '       Fixed =
TED#16678. O_GET_E'
Change 22075 on 2006/12/07 by jong@jong-jong-cifs 'Make sure that the =
default opti'
Change 22074 on 2006/12/07 by jobia@jobi:jobi '   Avoid a 4k stack usage =
while'
Change 22065 on 2006/12/06 by jobia@jobi:jobi '   EEK should remove all =
the in'
Change 22060 on 2006/12/05 by maximk@maximk-13 'Add some functions. '

EverON release images:

Cheetah Debug Build Image:

ftp://upgrade:password@10.2.0.2/home/upgrade/R2.1.0.0DBG-120906.tar.gz

Bobcat Debug Build Image:

ftp://upgrade:password@10.2.0.2/home/upgrade/R2.1.0.0BCDBG-120906.tar.gz

Cheetah Opt Build Image:

ftp://upgrade:password@10.2.0.2/home/upgrade/R2.1.0.0-120906.tar.gz

Bobcat Opt Build Image:

ftp://upgrade:password@10.2.0.2/home/upgrade/R2.1.0.0BC-120906.tar.gz

EverON Source tree:

/n/Build-Trees/R2.1.0.0/R2.1.0.0-120906/nfx-tree

Perforce sync info:

//depot/R2_1_X_work/=85@22122

I'll get out submittal notes as soon as I can, thanks.

-Ken

-----Original Message-----
From: Paul Hammer
Sent: Sat 12/9/2006 9:47 PM
To: Tim Gardner; Ken Renshaw; Vikas Saini; Sandrine Boulanger
Subject: RE: longest eek so far !!!
=20
Cool, Ken do we have a submittal?

________________________________

From: Tim Gardner
Sent: Sat 12/9/2006 5:47 PM
To: Ken Renshaw; Paul Hammer; Vikas Saini; Sandrine Boulanger
Subject: RE: longest eek so far !!!



take it. I approved the checkin.

-----Original Message-----
From: Ken Renshaw
Sent: Saturday, December 09, 2006 5:43 PM
To: Paul Hammer; Vikas Saini; Sandrine Boulanger; Tim Gardner
Subject: RE: longest eek so far !!!

It's just some functions for GDB that would be useful in debugging the =
tree, it's more or less a GDB script instead of a piece of EverON code. =
I'd vote for just leaving it, but can skip it if you'd like.


-----Original Message-----
From: Paul Hammer
Sent: Sat 12/9/2006 5:35 PM
To: Vikas Saini; Ken Renshaw; Sandrine Boulanger; Tim Gardner
Subject: RE: longest eek so far !!!

Thanks, guess we should take it, not sure why it is there. Tim do you =
know why this in in here?

________________________________

From: Vikas Saini
Sent: Sat 12/9/2006 4:33 PM
To: Paul Hammer; Ken Renshaw; Sandrine Boulanger
Subject: RE: longest eek so far !!!



excepy max check in, everything is in MF list for Clio


________________________________

From: Ken Renshaw
Sent: Sat 12/9/2006 2:49 PM
To: Paul Hammer; Sandrine Boulanger; Vikas Saini
Subject: RE: longest eek so far !!!



Here is what's been checked in since sub7 ( the last one is just some =
new GDB functions ):

Change 22122 on 2006/12/09 by jobia@jobi:jobi '   leftover changes for =
changes'
Change 22105 on 2006/12/08 by nagendras@nags_r21work 'Fix for TED16641 =
Wildcard chara'
Change 22076 on 2006/12/07 by henryl@henryl-linux '       Fixed =
TED#16678. O_GET_E'
Change 22075 on 2006/12/07 by jong@jong-jong-cifs 'Make sure that the =
default opti'
Change 22074 on 2006/12/07 by jobia@jobi:jobi '   Avoid a 4k stack usage =
while'
Change 22065 on 2006/12/06 by jobia@jobi:jobi '   EEK should remove all =
the in'
Change 22060 on 2006/12/05 by maximk@maximk-13 'Add some functions. '

Long descriptions:

Change 22122 by jobia@jobi:jobi on 2006/12/09 14:40:47

           leftover changes for changes made for defect TED00016681 and =
TED00016685.
           EEK should not dereference an inode/buffer, after unlocking =
the lock.
           Mark/Fix used blocks, using inode buffers instead of inodes.
   =20
           Reviewed by JonG.

Affected files ...

... //depot/R2_1_X_work/nfx-tree/code/sm-fs/btree/emaproot.c#6 edit
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-dir.c#5 edit
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-eek-quota.c#3 edit
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-eek-quota.h#2 edit
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-eek.c#21 edit
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-proto.h#4 edit

Change 22105 by nagendras@nags_r21work on 2006/12/08 10:48:45

        Fix for TED16641
        Wildcard characters were not being accepted for domain names in =
idmap rules.
   =20
        reviewed by briand

Affected files ...

... //depot/R2_1_X_work/nfx-tree/code/ssc-authen-lib/authen-lib-api.h#2 =
edit
... //depot/R2_1_X_work/nfx-tree/code/ssc-authen-lib/idmap-cfg.c#2 edit
... //depot/R2_1_X_work/nfx-tree/code/ssc-nfxsh/cmd_idmap.c#2 edit

Change 22076 by henryl@henryl-linux on 2006/12/07 10:07:59

               Fixed TED#16678. O_GET_EXCL() can return NULL buf if the =
file has a hole on that page offset or an error when caller failed to =
get blocking lock. Trigger a volume exception and send ELOG msg to print =
the page offset and inode number.
               Reviewed by Jobia

Affected files ...

... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-security.c#2 edit

Change 22075 by jong@jong-jong-cifs on 2006/12/07 09:56:28

        Make sure that the default option for creating a volume is =
normal
               stability.  This impacts mirror volume creation.
               This addresses defect 16718
               reviewed by JobiA

Affected files ...

... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-api.h#6 edit

Change 22074 by jobia@jobi:jobi on 2006/12/07 09:40:13

           Avoid a 4k stack usage while traversing the emap btrees.
   =20
           Corrupted special files were not being fixed correctly, thus =
would have
           generated errors in every eek run.
   =20
           Symbolic links with invalid numblocks are detected/fixed.
   =20
           A non-directory inode was checked for not to have quota tree =
root flag
           while traversing the directories.  If parent directory is =
missing, this
           check was missing for its children and thus a second eek =
would
           report those errors since the inode is in lost+found then.  =
Fix this
           issue first time itself.
   =20
           Added a function fs_eek_validateAndFix() to consolidate all =
the
           checks/fixes on a disk inode.
   =20
           Some minor changes in fs-debug.c.
   =20
           Defect TED00016681.
   =20
           Reviewed by JonG.

Affected files ...

... //depot/R2_1_X_work/nfx-tree/code/sm-fs/btree/emaproot.c#5 edit
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-debug.c#8 edit
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-eek.c#20 edit

Change 22065 by jobia@jobi:jobi on 2006/12/06 15:25:17

           EEK should remove all the inodes sharing the duplicate =
blocks.
   =20
           Defect 16685.
   =20
           Reviewed by JonG.

Affected files ...

... //depot/R2_1_X_work/nfx-tree/code/sm-fs/btree/emaproot.c#4 edit
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-eek.c#19 edit
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-eek.h#11 edit

Change 22060 by maximk@maximk-13 on 2006/12/05 14:44:29

        Add some functions.

Affected files ...

... //depot/R2_1_X_work/nfx-tree/gdbfuncs#2 edit

-----Original Message-----
From: Paul Hammer
Sent: Sat 12/9/2006 12:40 PM
To: Ken Renshaw; Sandrine Boulanger; Vikas Saini
Subject: RE: longest eek so far !!!

YOu bet, was hoping for an update from Tim/Dev about the mem leaks that =
have yet to fix.

-paul

________________________________

From: Ken Renshaw
Sent: Sat 12/9/2006 12:34 PM
To: Paul Hammer
Subject: Re: longest eek so far !!!



Hey Paul, likewise can you keep me in the loop for any Clio MFs or =
builds past the last submittal 7? I've not heard anything about an RC =
build, unless sub7 is considered RC1 by some.

Thanks,

-Ken



-----Original Message-----
From: Paul Hammer
To: Jobi Ariyamannil; Raj Kumar; Vikas Saini; Sandrine Boulanger; Jay =
Michlin; Henry Lau; Jerry Lopatin; Tim Gardner; Brian DeForest
CC: dl-QA
Sent: Sat Dec 09 12:06:49 2006
Subject: RE: longest eek so far !!!

Thanks Jobi.

Since this eek run is in the soak env I do not think the cfg has =
changed, Raj or Vikas can you confirm?

That is good news on the quotas, nice to hear that you have identified =
the problem.

We need to sync up on the eek part and the next submittal. As of now we =
are just waiting on the final two MF's to come through and then we =
should be done from the Dev perspectice. QA has already started the =
final regression pass on Clio and we hope to install the RC on MD on =
Monday. Did not know there was other changes being submitted, lets talk =
about how to proceed.

Should we change the defaults for shippinf eek? I asked Raj to rerun the =
eek tests for comparison in the default configuration since that is how =
we ship it and how I belive customers usually run it.

Good stuff Jobi, thanks.

-Paul


________________________________

From: Jobi Ariyamannil
Sent: Sat 12/9/2006 10:27 AM
To: Paul Hammer; Raj Kumar; Vikas Saini; Sandrine Boulanger; Jay =
Michlin; Henry Lau; Jerry Lopatin; Tim Gardner; Brian DeForest
Cc: dl-QA
Subject: RE: longest eek so far !!!



This time EEK has been running since Dec 6, 10am.

I also have been monitoring the eek progress this time.

Something strange happened this time, there were I/O retries and eek has =
been slowed down.

I looked at the code changes between submittal 4 and 7 and could not =
explain the difference in performance, so this must be something changed =
in the configuration.



Good news is that, I figured out why EEK is slow processing large number =
of quota records.

These issues cannot be fixed in 2.1.  If some customer complains about =
eek performance while processing large number of quota records, we have =
to suggest using the new eek option to skip processing quota records =
during eek.



There have been some more changes to eek after submittal 7.  We should =
restart eek on this filesystem once the next submittal is available.

In all my tests, eek in 2.1 is 40% faster than, that of in 133 (I =
verified this on a filesystem with 100 million inodes too).

It would be good if QA can validate this claim.



Also while running eek on filesystems of large size and large number of =
files and directories, using the default FP cache configuration is a =
very bad idea.

EEK can be made much faster by configuring the caches and this is =
something we strongly advise our customers too.



Regards,

Jobi



________________________________

From: Paul Hammer
Sent: Saturday, December 09, 2006 9:39 AM
To: Raj Kumar; Jobi Ariyamannil; Vikas Saini; Sandrine Boulanger; Jay =
Michlin; Henry Lau; Jerry Lopatin; Tim Gardner; Brian DeForest
Cc: dl-QA
Subject: RE: longest eek so far !!!



Raj, how long has this one been running?

________________________________

From: Raj Kumar
Sent: Sat 12/9/2006 6:57 AM
To: Paul Hammer; Jobi Ariyamannil; Vikas Saini; Sandrine Boulanger; Jay =
Michlin; Henry Lau; Jerry Lopatin; Tim Gardner; Brian DeForest
Cc: dl-QA
Subject: RE: longest eek so far !!!

Filer: eng49

Volume - eng49-3

Cache status captured every 10 minutes: /usr/raj/cache



EEK is still running. I am afraid this is going much worse than the last =
run. In the last run processing quotas took 90% of the time. This time =
we have not reached quota processing yet, delay is on "mark used =
inodes".



# fscmd eek eng49-3 -c -r

all snapshots  will be removed.

running eek in repair mode

Wed Dec  6 10:10:53 2006 =3D=3D eng49-3 =3D=3D verifying meta inodes =
=3D=3D

eng49-3: removing snapshots

Wed Dec  6 10:11:30 2006 =3D=3D eng49-3 =3D=3D mark and compare =
reference counts =3D=3D

Wed Dec  6 10:11:33 2006 =3D=3D eng49-3 =3D=3D mark used blocks =3D=3D

processed 194314240 of 194314240 inodes



Wed Dec  6 11:18:58 2006 =3D=3D eng49-3 =3D=3D compare used blocks =
=3D=3D

processed 0 of 105574336 blocks



Thu Dec  7 07:49:08 2006 =3D=3D eng49-3 =3D=3D processing quota trees =
=3D=3D

processed 1 quota tree records

Thu Dec  7 07:49:09 2006 =3D=3D eng49-3 =3D=3D mark used inodes =3D=3D

processed 68719104 of 194314240 inodes, 10145703 of 16441522 directories



________________________________

From: Paul Hammer
Sent: Wednesday, December 06, 2006 8:35 AM
To: Jobi Ariyamannil; Vikas Saini; Sandrine Boulanger; Jay Michlin; =
Henry Lau; Jerry Lopatin; Tim Gardner; Brian DeForest
Cc: dl-QA
Subject: RE: longest eek so far !!!



Thanks Jobi. Vikas please let us know how the rerun of eek goes, thanks.



-Paul



________________________________

From: Jobi Ariyamannil
Sent: Wed 12/6/2006 12:25 AM
To: Paul Hammer; Vikas Saini; Sandrine Boulanger; Jay Michlin; Henry =
Lau; Jerry Lopatin; Tim Gardner; Brian DeForest
Cc: dl-QA
Subject: RE: longest eek so far !!!

Hi Paul,



There have been many improvements to eek, but most of them not going to =
improve eek processing time of large number of quota records.

We still don't know what is causing bad eek performance while processing =
large number of quota records.



But we made an obvious improvement to eek (issue read aheads of quota =
records) hoping to make eek faster while processing the quota records.

We have not verified how much this change would help.  Testing with =
submittal 7 would verify this.



Also we added an argument to eek which if specified, will skip quota =
checks.  Using that option, the given filesystem can be eeked in one day =
or so (which is reasonable considering the large number of =
inodes/directories etc).



Also we may be able to configure the caches on the filer to get better =
performance from eek.



Surprisingly, no customers so far reported so many quota records.



Regards,

Jobi



________________________________

From: Paul Hammer
Sent: Tuesday, December 05, 2006 11:29 PM
To: Jobi Ariyamannil; Vikas Saini; Sandrine Boulanger; Jay Michlin; =
Henry Lau; Jerry Lopatin; Tim Gardner; Brian DeForest
Cc: dl-QA
Subject: RE: longest eek so far !!!



Hi Jobi,



Are there any improvements since we started this eek run (2 submittals =
ago) that will reduce the amount of time eek takes in a quotated env? =
What I am really asking is: will customers with quotas set see this type =
of eek performance, potentially take weeks to run eek with 2.1?



I have asked Vikas that we rerun the eek test on the same volume in the =
soak env to see if we are now faster, vikas let me know that even though =
it took 16 days that eek only fixed one problem.



Thanks,



-Paul



________________________________

From: Jobi Ariyamannil
Sent: Tue 12/5/2006 8:11 PM
To: Vikas Saini; Sandrine Boulanger; Jay Michlin; Henry Lau; Jerry =
Lopatin; Tim Gardner; Brian DeForest
Cc: dl-QA
Subject: RE: longest eek so far !!!

Its again spent a lot of days processing quota records.  Rest of the =
passes look reasonable.

Submital 7 will have an option in eek to skip quota records passing =
("-q") option.

Going forward, while reporting eek delays, please mention the build =
info, fscmd cachestats output.

As we have added read ahead of quota records in submittal 7, we may test =
that too.

Regards,

Jobi

_____________________________________________
From: Vikas Saini
Sent: Tuesday, December 05, 2006 8:07 PM
To: Sandrine Boulanger; Jay Michlin; Jobi Ariyamannil; Henry Lau; Jerry =
Lopatin; Tim Gardner; Brian DeForest
Cc: dl-QA
Subject: longest eek so far !!!
Importance: High

Live view done. Eek for snapshot is still going on. Going to abort the =
snapshot eek.



# fscmd eek eng49-3 lvolOnline -r -f

running eek in repair mode

Force mode: corrupt snapshots  will be automatically removed.

volId 0x17a000000d0 is not online, state is 1

eek: trying to bring the logical volume online

Done.

Mon Nov 20 09:22:21 2006 =3D=3D eng49-3 =3D=3D verifying meta inodes =
=3D=3D

eng49-3: Inode (I#1) file invalid numblocks 3036141 in superblock, =
expected 3036142

Mon Nov 20 09:22:35 2006 =3D=3D eng49-3 =3D=3D mark and compare =
reference counts =3D=3D

Mon Nov 20 09:23:08 2006 =3D=3D eng49-3 =3D=3D mark used blocks =3D=3D

eng49-3: Inode (I#1) file invalid numblocks 3036141 in superblock, =
expected 3036142

processed 194314240 of 194314240 inodes

Mon Nov 20 10:20:38 2006 =3D=3D eng49-3 =3D=3D compare used blocks =
=3D=3D

processed 105574336 of 105574336 blocks

Mon Nov 20 11:31:12 2006 =3D=3D eng49-3 =3D=3D processing quota trees =
=3D=3D

processed 1 quota tree records

Mon Nov 20 11:31:12 2006 =3D=3D eng49-3 =3D=3D mark used inodes =3D=3D

proceprocessed 194314240 of 194314240 inodes, 16441522 of 16441522 =
directories

Tue Nov 21 01:42:55 2006 =3D=3D eng49-3 =3D=3D detecting unused quota =
trees =3D=3D

Tue Nov 21 01:42:55 2006 =3D=3D eng49-3 =3D=3D processing user quotas =
=3D=3D

processed 1220544 user quota records

processed 2466048 user quota records

processed 3185126 user quota records

Sat Dec  2 06:52:15 2006 =3D=3D eng49-3 =3D=3D processing group quotas =
=3D=3D

processed 1 group quota records

Sat Dec  2 06:53:01 2006 =3D=3D eng49-3 =3D=3D compare used inodes =
=3D=3D

processed 194314240 of 194314240 inodes, 16441522 of 16441522 =
directories

Sun Dec  3 22:36:46 2006 =3D=3D eng49-3 =3D=3D user quota not enabled - =
usage verification skipped =3D=3D

Sun Dec  3 22:36:46 2006 =3D=3D eng49-3 =3D=3D group quota not enabled - =
usage verification skipped =3D=3D

Sun Dec  3 22:36:46 2006 =3D=3D eng49-3 =3D=3D relink lost inodes =3D=3D

Sun Dec  3 22:37:22 2006 =3D=3D eng49-3 =3D=3D verify link inode =3D=3D

Mon Dec  4 10:49:19 2006 =3D=3D eng49-3 =3D=3D live view done =3D=3D  =
blksUsed 88207888 inodesUsed 58298273 =3D=3D

Mon Dec  4 10:49:19 2006 =3D=3D eng49-3 =3D=3D checking snapshots =3D=3D















------_=_NextPart_001_01C71C83.432C00A9
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7650.28">
<TITLE>Clio R2.1 Submittal 8 - RC1 available for testing</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi All,<BR>
&nbsp;&nbsp; Clio R2.1 Submittal 8 - RC1 is available for testing. =
Please load this for your Clio testing and continue with your =
regression. we need to load this on our soak systems also so that we =
have atleast a couple of days runtime before we load this on =
mightydog.<BR>
<BR>
Thanks<BR>
Vikas<BR>
<BR>
-----Original Message-----<BR>
From: Ken Renshaw<BR>
Sent: Sat 12/9/2006 9:49 PM<BR>
To: Paul Hammer; Tim Gardner; Vikas Saini; Sandrine Boulanger<BR>
Cc: Ken Renshaw<BR>
Subject: Clio R2.1 Submittal 8 - RC1 Images Ready for Test - Was: RE: =
longest eek so far !!!<BR>
<BR>
Yep, here's the package info, I'll complete submittal notes tomorrow if =
that's alright:<BR>
<BR>
Changes since submittal 7:<BR>
<BR>
Change 22122 on 2006/12/09 by jobia@jobi:jobi '&nbsp;&nbsp; leftover =
changes for changes'<BR>
Change 22105 on 2006/12/08 by nagendras@nags_r21work 'Fix for TED16641 =
Wildcard chara'<BR>
Change 22076 on 2006/12/07 by henryl@henryl-linux =
'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fixed TED#16678. O_GET_E'<BR>
Change 22075 on 2006/12/07 by jong@jong-jong-cifs 'Make sure that the =
default opti'<BR>
Change 22074 on 2006/12/07 by jobia@jobi:jobi '&nbsp;&nbsp; Avoid a 4k =
stack usage while'<BR>
Change 22065 on 2006/12/06 by jobia@jobi:jobi '&nbsp;&nbsp; EEK should =
remove all the in'<BR>
Change 22060 on 2006/12/05 by maximk@maximk-13 'Add some functions. =
'<BR>
<BR>
EverON release images:<BR>
<BR>
Cheetah Debug Build Image:<BR>
<BR>
<A =
HREF=3D"ftp://upgrade:password@10.2.0.2/home/upgrade/R2.1.0.0DBG-120906.t=
ar.gz">ftp://upgrade:password@10.2.0.2/home/upgrade/R2.1.0.0DBG-120906.ta=
r.gz</A><BR>
<BR>
Bobcat Debug Build Image:<BR>
<BR>
<A =
HREF=3D"ftp://upgrade:password@10.2.0.2/home/upgrade/R2.1.0.0BCDBG-120906=
.tar.gz">ftp://upgrade:password@10.2.0.2/home/upgrade/R2.1.0.0BCDBG-12090=
6.tar.gz</A><BR>
<BR>
Cheetah Opt Build Image:<BR>
<BR>
<A =
HREF=3D"ftp://upgrade:password@10.2.0.2/home/upgrade/R2.1.0.0-120906.tar.=
gz">ftp://upgrade:password@10.2.0.2/home/upgrade/R2.1.0.0-120906.tar.gz</=
A><BR>
<BR>
Bobcat Opt Build Image:<BR>
<BR>
<A =
HREF=3D"ftp://upgrade:password@10.2.0.2/home/upgrade/R2.1.0.0BC-120906.ta=
r.gz">ftp://upgrade:password@10.2.0.2/home/upgrade/R2.1.0.0BC-120906.tar.=
gz</A><BR>
<BR>
EverON Source tree:<BR>
<BR>
/n/Build-Trees/R2.1.0.0/R2.1.0.0-120906/nfx-tree<BR>
<BR>
Perforce sync info:<BR>
<BR>
//depot/R2_1_X_work/&#133;@22122<BR>
<BR>
I'll get out submittal notes as soon as I can, thanks.<BR>
<BR>
-Ken<BR>
<BR>
-----Original Message-----<BR>
From: Paul Hammer<BR>
Sent: Sat 12/9/2006 9:47 PM<BR>
To: Tim Gardner; Ken Renshaw; Vikas Saini; Sandrine Boulanger<BR>
Subject: RE: longest eek so far !!!<BR>
<BR>
Cool, Ken do we have a submittal?<BR>
<BR>
________________________________<BR>
<BR>
From: Tim Gardner<BR>
Sent: Sat 12/9/2006 5:47 PM<BR>
To: Ken Renshaw; Paul Hammer; Vikas Saini; Sandrine Boulanger<BR>
Subject: RE: longest eek so far !!!<BR>
<BR>
<BR>
<BR>
take it. I approved the checkin.<BR>
<BR>
-----Original Message-----<BR>
From: Ken Renshaw<BR>
Sent: Saturday, December 09, 2006 5:43 PM<BR>
To: Paul Hammer; Vikas Saini; Sandrine Boulanger; Tim Gardner<BR>
Subject: RE: longest eek so far !!!<BR>
<BR>
It's just some functions for GDB that would be useful in debugging the =
tree, it's more or less a GDB script instead of a piece of EverON code. =
I'd vote for just leaving it, but can skip it if you'd like.<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Paul Hammer<BR>
Sent: Sat 12/9/2006 5:35 PM<BR>
To: Vikas Saini; Ken Renshaw; Sandrine Boulanger; Tim Gardner<BR>
Subject: RE: longest eek so far !!!<BR>
<BR>
Thanks, guess we should take it, not sure why it is there. Tim do you =
know why this in in here?<BR>
<BR>
________________________________<BR>
<BR>
From: Vikas Saini<BR>
Sent: Sat 12/9/2006 4:33 PM<BR>
To: Paul Hammer; Ken Renshaw; Sandrine Boulanger<BR>
Subject: RE: longest eek so far !!!<BR>
<BR>
<BR>
<BR>
excepy max check in, everything is in MF list for Clio<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Ken Renshaw<BR>
Sent: Sat 12/9/2006 2:49 PM<BR>
To: Paul Hammer; Sandrine Boulanger; Vikas Saini<BR>
Subject: RE: longest eek so far !!!<BR>
<BR>
<BR>
<BR>
Here is what's been checked in since sub7 ( the last one is just some =
new GDB functions ):<BR>
<BR>
Change 22122 on 2006/12/09 by jobia@jobi:jobi '&nbsp;&nbsp; leftover =
changes for changes'<BR>
Change 22105 on 2006/12/08 by nagendras@nags_r21work 'Fix for TED16641 =
Wildcard chara'<BR>
Change 22076 on 2006/12/07 by henryl@henryl-linux =
'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fixed TED#16678. O_GET_E'<BR>
Change 22075 on 2006/12/07 by jong@jong-jong-cifs 'Make sure that the =
default opti'<BR>
Change 22074 on 2006/12/07 by jobia@jobi:jobi '&nbsp;&nbsp; Avoid a 4k =
stack usage while'<BR>
Change 22065 on 2006/12/06 by jobia@jobi:jobi '&nbsp;&nbsp; EEK should =
remove all the in'<BR>
Change 22060 on 2006/12/05 by maximk@maximk-13 'Add some functions. =
'<BR>
<BR>
Long descriptions:<BR>
<BR>
Change 22122 by jobia@jobi:jobi on 2006/12/09 14:40:47<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leftover =
changes for changes made for defect TED00016681 and TED00016685.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EEK should =
not dereference an inode/buffer, after unlocking the lock.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mark/Fix =
used blocks, using inode buffers instead of inodes.<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reviewed by =
JonG.<BR>
<BR>
Affected files ...<BR>
<BR>
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/btree/emaproot.c#6 edit<BR>
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-dir.c#5 edit<BR>
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-eek-quota.c#3 edit<BR>
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-eek-quota.h#2 edit<BR>
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-eek.c#21 edit<BR>
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-proto.h#4 edit<BR>
<BR>
Change 22105 by nagendras@nags_r21work on 2006/12/08 10:48:45<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fix for TED16641<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Wildcard characters were not =
being accepted for domain names in idmap rules.<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reviewed by briand<BR>
<BR>
Affected files ...<BR>
<BR>
... //depot/R2_1_X_work/nfx-tree/code/ssc-authen-lib/authen-lib-api.h#2 =
edit<BR>
... //depot/R2_1_X_work/nfx-tree/code/ssc-authen-lib/idmap-cfg.c#2 =
edit<BR>
... //depot/R2_1_X_work/nfx-tree/code/ssc-nfxsh/cmd_idmap.c#2 edit<BR>
<BR>
Change 22076 by henryl@henryl-linux on 2006/12/07 10:07:59<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; Fixed TED#16678. O_GET_EXCL() can return NULL buf if the =
file has a hole on that page offset or an error when caller failed to =
get blocking lock. Trigger a volume exception and send ELOG msg to print =
the page offset and inode number.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; Reviewed by Jobia<BR>
<BR>
Affected files ...<BR>
<BR>
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-security.c#2 edit<BR>
<BR>
Change 22075 by jong@jong-jong-cifs on 2006/12/07 09:56:28<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Make sure that the default =
option for creating a volume is normal<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; stability.&nbsp; This impacts mirror volume creation.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; This addresses defect 16718<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; reviewed by JobiA<BR>
<BR>
Affected files ...<BR>
<BR>
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-api.h#6 edit<BR>
<BR>
Change 22074 by jobia@jobi:jobi on 2006/12/07 09:40:13<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Avoid a 4k =
stack usage while traversing the emap btrees.<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Corrupted =
special files were not being fixed correctly, thus would have<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; generated =
errors in every eek run.<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Symbolic =
links with invalid numblocks are detected/fixed.<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A =
non-directory inode was checked for not to have quota tree root flag<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; while =
traversing the directories.&nbsp; If parent directory is missing, =
this<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; check was =
missing for its children and thus a second eek would<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; report =
those errors since the inode is in lost+found then.&nbsp; Fix this<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; issue first =
time itself.<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Added a =
function fs_eek_validateAndFix() to consolidate all the<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
checks/fixes on a disk inode.<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Some minor =
changes in fs-debug.c.<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Defect =
TED00016681.<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reviewed by =
JonG.<BR>
<BR>
Affected files ...<BR>
<BR>
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/btree/emaproot.c#5 edit<BR>
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-debug.c#8 edit<BR>
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-eek.c#20 edit<BR>
<BR>
Change 22065 by jobia@jobi:jobi on 2006/12/06 15:25:17<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EEK should =
remove all the inodes sharing the duplicate blocks.<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Defect =
16685.<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reviewed by =
JonG.<BR>
<BR>
Affected files ...<BR>
<BR>
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/btree/emaproot.c#4 edit<BR>
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-eek.c#19 edit<BR>
... //depot/R2_1_X_work/nfx-tree/code/sm-fs/fs-eek.h#11 edit<BR>
<BR>
Change 22060 by maximk@maximk-13 on 2006/12/05 14:44:29<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add some functions.<BR>
<BR>
Affected files ...<BR>
<BR>
... //depot/R2_1_X_work/nfx-tree/gdbfuncs#2 edit<BR>
<BR>
-----Original Message-----<BR>
From: Paul Hammer<BR>
Sent: Sat 12/9/2006 12:40 PM<BR>
To: Ken Renshaw; Sandrine Boulanger; Vikas Saini<BR>
Subject: RE: longest eek so far !!!<BR>
<BR>
YOu bet, was hoping for an update from Tim/Dev about the mem leaks that =
have yet to fix.<BR>
<BR>
-paul<BR>
<BR>
________________________________<BR>
<BR>
From: Ken Renshaw<BR>
Sent: Sat 12/9/2006 12:34 PM<BR>
To: Paul Hammer<BR>
Subject: Re: longest eek so far !!!<BR>
<BR>
<BR>
<BR>
Hey Paul, likewise can you keep me in the loop for any Clio MFs or =
builds past the last submittal 7? I've not heard anything about an RC =
build, unless sub7 is considered RC1 by some.<BR>
<BR>
Thanks,<BR>
<BR>
-Ken<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Paul Hammer<BR>
To: Jobi Ariyamannil; Raj Kumar; Vikas Saini; Sandrine Boulanger; Jay =
Michlin; Henry Lau; Jerry Lopatin; Tim Gardner; Brian DeForest<BR>
CC: dl-QA<BR>
Sent: Sat Dec 09 12:06:49 2006<BR>
Subject: RE: longest eek so far !!!<BR>
<BR>
Thanks Jobi.<BR>
<BR>
Since this eek run is in the soak env I do not think the cfg has =
changed, Raj or Vikas can you confirm?<BR>
<BR>
That is good news on the quotas, nice to hear that you have identified =
the problem.<BR>
<BR>
We need to sync up on the eek part and the next submittal. As of now we =
are just waiting on the final two MF's to come through and then we =
should be done from the Dev perspectice. QA has already started the =
final regression pass on Clio and we hope to install the RC on MD on =
Monday. Did not know there was other changes being submitted, lets talk =
about how to proceed.<BR>
<BR>
Should we change the defaults for shippinf eek? I asked Raj to rerun the =
eek tests for comparison in the default configuration since that is how =
we ship it and how I belive customers usually run it.<BR>
<BR>
Good stuff Jobi, thanks.<BR>
<BR>
-Paul<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Jobi Ariyamannil<BR>
Sent: Sat 12/9/2006 10:27 AM<BR>
To: Paul Hammer; Raj Kumar; Vikas Saini; Sandrine Boulanger; Jay =
Michlin; Henry Lau; Jerry Lopatin; Tim Gardner; Brian DeForest<BR>
Cc: dl-QA<BR>
Subject: RE: longest eek so far !!!<BR>
<BR>
<BR>
<BR>
This time EEK has been running since Dec 6, 10am.<BR>
<BR>
I also have been monitoring the eek progress this time.<BR>
<BR>
Something strange happened this time, there were I/O retries and eek has =
been slowed down.<BR>
<BR>
I looked at the code changes between submittal 4 and 7 and could not =
explain the difference in performance, so this must be something changed =
in the configuration.<BR>
<BR>
<BR>
<BR>
Good news is that, I figured out why EEK is slow processing large number =
of quota records.<BR>
<BR>
These issues cannot be fixed in 2.1.&nbsp; If some customer complains =
about eek performance while processing large number of quota records, we =
have to suggest using the new eek option to skip processing quota =
records during eek.<BR>
<BR>
<BR>
<BR>
There have been some more changes to eek after submittal 7.&nbsp; We =
should restart eek on this filesystem once the next submittal is =
available.<BR>
<BR>
In all my tests, eek in 2.1 is 40% faster than, that of in 133 (I =
verified this on a filesystem with 100 million inodes too).<BR>
<BR>
It would be good if QA can validate this claim.<BR>
<BR>
<BR>
<BR>
Also while running eek on filesystems of large size and large number of =
files and directories, using the default FP cache configuration is a =
very bad idea.<BR>
<BR>
EEK can be made much faster by configuring the caches and this is =
something we strongly advise our customers too.<BR>
<BR>
<BR>
<BR>
Regards,<BR>
<BR>
Jobi<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Paul Hammer<BR>
Sent: Saturday, December 09, 2006 9:39 AM<BR>
To: Raj Kumar; Jobi Ariyamannil; Vikas Saini; Sandrine Boulanger; Jay =
Michlin; Henry Lau; Jerry Lopatin; Tim Gardner; Brian DeForest<BR>
Cc: dl-QA<BR>
Subject: RE: longest eek so far !!!<BR>
<BR>
<BR>
<BR>
Raj, how long has this one been running?<BR>
<BR>
________________________________<BR>
<BR>
From: Raj Kumar<BR>
Sent: Sat 12/9/2006 6:57 AM<BR>
To: Paul Hammer; Jobi Ariyamannil; Vikas Saini; Sandrine Boulanger; Jay =
Michlin; Henry Lau; Jerry Lopatin; Tim Gardner; Brian DeForest<BR>
Cc: dl-QA<BR>
Subject: RE: longest eek so far !!!<BR>
<BR>
Filer: eng49<BR>
<BR>
Volume - eng49-3<BR>
<BR>
Cache status captured every 10 minutes: /usr/raj/cache<BR>
<BR>
<BR>
<BR>
EEK is still running. I am afraid this is going much worse than the last =
run. In the last run processing quotas took 90% of the time. This time =
we have not reached quota processing yet, delay is on &quot;mark used =
inodes&quot;.<BR>
<BR>
<BR>
<BR>
# fscmd eek eng49-3 -c -r<BR>
<BR>
all snapshots&nbsp; will be removed.<BR>
<BR>
running eek in repair mode<BR>
<BR>
Wed Dec&nbsp; 6 10:10:53 2006 =3D=3D eng49-3 =3D=3D verifying meta =
inodes =3D=3D<BR>
<BR>
eng49-3: removing snapshots<BR>
<BR>
Wed Dec&nbsp; 6 10:11:30 2006 =3D=3D eng49-3 =3D=3D mark and compare =
reference counts =3D=3D<BR>
<BR>
Wed Dec&nbsp; 6 10:11:33 2006 =3D=3D eng49-3 =3D=3D mark used blocks =
=3D=3D<BR>
<BR>
processed 194314240 of 194314240 inodes<BR>
<BR>
<BR>
<BR>
Wed Dec&nbsp; 6 11:18:58 2006 =3D=3D eng49-3 =3D=3D compare used blocks =
=3D=3D<BR>
<BR>
processed 0 of 105574336 blocks<BR>
<BR>
<BR>
<BR>
Thu Dec&nbsp; 7 07:49:08 2006 =3D=3D eng49-3 =3D=3D processing quota =
trees =3D=3D<BR>
<BR>
processed 1 quota tree records<BR>
<BR>
Thu Dec&nbsp; 7 07:49:09 2006 =3D=3D eng49-3 =3D=3D mark used inodes =
=3D=3D<BR>
<BR>
processed 68719104 of 194314240 inodes, 10145703 of 16441522 =
directories<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Paul Hammer<BR>
Sent: Wednesday, December 06, 2006 8:35 AM<BR>
To: Jobi Ariyamannil; Vikas Saini; Sandrine Boulanger; Jay Michlin; =
Henry Lau; Jerry Lopatin; Tim Gardner; Brian DeForest<BR>
Cc: dl-QA<BR>
Subject: RE: longest eek so far !!!<BR>
<BR>
<BR>
<BR>
Thanks Jobi. Vikas please let us know how the rerun of eek goes, =
thanks.<BR>
<BR>
<BR>
<BR>
-Paul<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Jobi Ariyamannil<BR>
Sent: Wed 12/6/2006 12:25 AM<BR>
To: Paul Hammer; Vikas Saini; Sandrine Boulanger; Jay Michlin; Henry =
Lau; Jerry Lopatin; Tim Gardner; Brian DeForest<BR>
Cc: dl-QA<BR>
Subject: RE: longest eek so far !!!<BR>
<BR>
Hi Paul,<BR>
<BR>
<BR>
<BR>
There have been many improvements to eek, but most of them not going to =
improve eek processing time of large number of quota records.<BR>
<BR>
We still don't know what is causing bad eek performance while processing =
large number of quota records.<BR>
<BR>
<BR>
<BR>
But we made an obvious improvement to eek (issue read aheads of quota =
records) hoping to make eek faster while processing the quota =
records.<BR>
<BR>
We have not verified how much this change would help.&nbsp; Testing with =
submittal 7 would verify this.<BR>
<BR>
<BR>
<BR>
Also we added an argument to eek which if specified, will skip quota =
checks.&nbsp; Using that option, the given filesystem can be eeked in =
one day or so (which is reasonable considering the large number of =
inodes/directories etc).<BR>
<BR>
<BR>
<BR>
Also we may be able to configure the caches on the filer to get better =
performance from eek.<BR>
<BR>
<BR>
<BR>
Surprisingly, no customers so far reported so many quota records.<BR>
<BR>
<BR>
<BR>
Regards,<BR>
<BR>
Jobi<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Paul Hammer<BR>
Sent: Tuesday, December 05, 2006 11:29 PM<BR>
To: Jobi Ariyamannil; Vikas Saini; Sandrine Boulanger; Jay Michlin; =
Henry Lau; Jerry Lopatin; Tim Gardner; Brian DeForest<BR>
Cc: dl-QA<BR>
Subject: RE: longest eek so far !!!<BR>
<BR>
<BR>
<BR>
Hi Jobi,<BR>
<BR>
<BR>
<BR>
Are there any improvements since we started this eek run (2 submittals =
ago) that will reduce the amount of time eek takes in a quotated env? =
What I am really asking is: will customers with quotas set see this type =
of eek performance, potentially take weeks to run eek with 2.1?<BR>
<BR>
<BR>
<BR>
I have asked Vikas that we rerun the eek test on the same volume in the =
soak env to see if we are now faster, vikas let me know that even though =
it took 16 days that eek only fixed one problem.<BR>
<BR>
<BR>
<BR>
Thanks,<BR>
<BR>
<BR>
<BR>
-Paul<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Jobi Ariyamannil<BR>
Sent: Tue 12/5/2006 8:11 PM<BR>
To: Vikas Saini; Sandrine Boulanger; Jay Michlin; Henry Lau; Jerry =
Lopatin; Tim Gardner; Brian DeForest<BR>
Cc: dl-QA<BR>
Subject: RE: longest eek so far !!!<BR>
<BR>
Its again spent a lot of days processing quota records.&nbsp; Rest of =
the passes look reasonable.<BR>
<BR>
Submital 7 will have an option in eek to skip quota records passing =
(&quot;-q&quot;) option.<BR>
<BR>
Going forward, while reporting eek delays, please mention the build =
info, fscmd cachestats output.<BR>
<BR>
As we have added read ahead of quota records in submittal 7, we may test =
that too.<BR>
<BR>
Regards,<BR>
<BR>
Jobi<BR>
<BR>
_____________________________________________<BR>
From: Vikas Saini<BR>
Sent: Tuesday, December 05, 2006 8:07 PM<BR>
To: Sandrine Boulanger; Jay Michlin; Jobi Ariyamannil; Henry Lau; Jerry =
Lopatin; Tim Gardner; Brian DeForest<BR>
Cc: dl-QA<BR>
Subject: longest eek so far !!!<BR>
Importance: High<BR>
<BR>
Live view done. Eek for snapshot is still going on. Going to abort the =
snapshot eek.<BR>
<BR>
<BR>
<BR>
# fscmd eek eng49-3 lvolOnline -r -f<BR>
<BR>
running eek in repair mode<BR>
<BR>
Force mode: corrupt snapshots&nbsp; will be automatically removed.<BR>
<BR>
volId 0x17a000000d0 is not online, state is 1<BR>
<BR>
eek: trying to bring the logical volume online<BR>
<BR>
Done.<BR>
<BR>
Mon Nov 20 09:22:21 2006 =3D=3D eng49-3 =3D=3D verifying meta inodes =
=3D=3D<BR>
<BR>
eng49-3: Inode (I#1) file invalid numblocks 3036141 in superblock, =
expected 3036142<BR>
<BR>
Mon Nov 20 09:22:35 2006 =3D=3D eng49-3 =3D=3D mark and compare =
reference counts =3D=3D<BR>
<BR>
Mon Nov 20 09:23:08 2006 =3D=3D eng49-3 =3D=3D mark used blocks =
=3D=3D<BR>
<BR>
eng49-3: Inode (I#1) file invalid numblocks 3036141 in superblock, =
expected 3036142<BR>
<BR>
processed 194314240 of 194314240 inodes<BR>
<BR>
Mon Nov 20 10:20:38 2006 =3D=3D eng49-3 =3D=3D compare used blocks =
=3D=3D<BR>
<BR>
processed 105574336 of 105574336 blocks<BR>
<BR>
Mon Nov 20 11:31:12 2006 =3D=3D eng49-3 =3D=3D processing quota trees =
=3D=3D<BR>
<BR>
processed 1 quota tree records<BR>
<BR>
Mon Nov 20 11:31:12 2006 =3D=3D eng49-3 =3D=3D mark used inodes =
=3D=3D<BR>
<BR>
proceprocessed 194314240 of 194314240 inodes, 16441522 of 16441522 =
directories<BR>
<BR>
Tue Nov 21 01:42:55 2006 =3D=3D eng49-3 =3D=3D detecting unused quota =
trees =3D=3D<BR>
<BR>
Tue Nov 21 01:42:55 2006 =3D=3D eng49-3 =3D=3D processing user quotas =
=3D=3D<BR>
<BR>
processed 1220544 user quota records<BR>
<BR>
processed 2466048 user quota records<BR>
<BR>
processed 3185126 user quota records<BR>
<BR>
Sat Dec&nbsp; 2 06:52:15 2006 =3D=3D eng49-3 =3D=3D processing group =
quotas =3D=3D<BR>
<BR>
processed 1 group quota records<BR>
<BR>
Sat Dec&nbsp; 2 06:53:01 2006 =3D=3D eng49-3 =3D=3D compare used inodes =
=3D=3D<BR>
<BR>
processed 194314240 of 194314240 inodes, 16441522 of 16441522 =
directories<BR>
<BR>
Sun Dec&nbsp; 3 22:36:46 2006 =3D=3D eng49-3 =3D=3D user quota not =
enabled - usage verification skipped =3D=3D<BR>
<BR>
Sun Dec&nbsp; 3 22:36:46 2006 =3D=3D eng49-3 =3D=3D group quota not =
enabled - usage verification skipped =3D=3D<BR>
<BR>
Sun Dec&nbsp; 3 22:36:46 2006 =3D=3D eng49-3 =3D=3D relink lost inodes =
=3D=3D<BR>
<BR>
Sun Dec&nbsp; 3 22:37:22 2006 =3D=3D eng49-3 =3D=3D verify link inode =
=3D=3D<BR>
<BR>
Mon Dec&nbsp; 4 10:49:19 2006 =3D=3D eng49-3 =3D=3D live view done =
=3D=3D&nbsp; blksUsed 88207888 inodesUsed 58298273 =3D=3D<BR>
<BR>
Mon Dec&nbsp; 4 10:49:19 2006 =3D=3D eng49-3 =3D=3D checking snapshots =
=3D=3D<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C71C83.432C00A9--
