X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C71D32.93DCB3A5@onstor-exch02.onstor.net>; Mon, 11 Dec 2006 06:42:26 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C71D32.93DCB3A5"
Content-class: urn:content-classes:message
Subject: RE: Clio R2.1 Submittal 8 - RC1 available for testing (EEK update)
Date: Mon, 11 Dec 2006 06:37:53 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04EF6A7B6@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Clio R2.1 Submittal 8 - RC1 available for testing (EEK update)
thread-index: AccY6/XzKxRmRVxQTvi9NBdZ0ywc+gAADiSQAAbM7tAAAeZNsAARW7xBAJNWRsAABc1NtAABUlQwAAOaxqQAASwOtgAANxJGAASDiMcAAbTpVAAB8VYMAAIqP8wAADyx3AAAKBSgAAhm87oAAAvDIwAY+87fAASclkIAJyn/Dg==
References: <BB375AF679D4A34E9CA8DFA650E2B04EF6A7B0@onstor-exch02.onstor.net>
From: "Raj Kumar" <raj.kumar@onstor.com>
To: "Raj Kumar" <raj.kumar@onstor.com>,
	"Vikas Saini" <vikas.saini@onstor.com>,
	"dl-Clio" <dl-Clio@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C71D32.93DCB3A5
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

EEK run is looking good. Already in the quota processing.
=20
# fscmd eek eng49-3 -r -c
running eek in repair mode
all snapshots  will be removed.
Sun Dec 10 11:58:24 2006 =3D=3D eng49-3 =3D=3D verifying meta inodes =
=3D=3D
eng49-3: removing snapshots
Sun Dec 10 11:58:48 2006 =3D=3D eng49-3 =3D=3D mark and compare =
reference counts =3D=3D
Sun Dec 10 11:58:51 2006 =3D=3D eng49-3 =3D=3D mark used blocks =3D=3D
processed 194314240 of 194314240 inodes
Sun Dec 10 12:58:53 2006 =3D=3D eng49-3 =3D=3D compare used blocks =
=3D=3D
Sun Dec 10 14:20:46 2006 =3D=3D eng49-3 =3D=3D processing quota trees =
=3D=3D
processed 1 quota tree records
Sun Dec 10 14:20:47 2006 =3D=3D eng49-3 =3D=3D mark used inodes =3D=3D
processed 194314240 of 194314240 inodes, 16441522 of 16441522 =
directories
Mon Dec 11 03:58:52 2006 =3D=3D eng49-3 =3D=3D detecting unused quota =
trees =3D=3D
Mon Dec 11 03:58:52 2006 =3D=3D eng49-3 =3D=3D processing user quotas =
=3D=3D
processed 326040 user quota records

________________________________

From: Raj Kumar
Sent: Sun 12/10/2006 11:56 AM
To: Vikas Saini; dl-Clio
Subject: RE: Clio R2.1 Submittal 8 - RC1 available for testing



Upgraded BC soak.

Started the EEK on the volume that we have issues in processing quotas =
records. Will update on the progress.


-----Original Message-----
From: Vikas Saini
Sent: Sun 12/10/2006 9:44 AM
To: dl-Clio
Subject: Clio R2.1 Submittal 8 - RC1 available for testing

Hi All,
   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 !!!

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/...@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 !!!

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_01C71D32.93DCB3A5
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>RE: Clio R2.1 Submittal 8 - RC1 available =
for testing</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.2900.2995" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText61882 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>EEK run is =
looking good. Already in the quota processing.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr># fscmd eek eng49-3 -r -c<BR>running eek in repair =
mode<BR>all snapshots&nbsp; will be removed.<BR>Sun Dec 10 11:58:24 2006 =
=3D=3D eng49-3 =3D=3D verifying meta inodes =3D=3D<BR>eng49-3: removing =
snapshots<BR>Sun Dec 10 11:58:48 2006 =3D=3D eng49-3 =3D=3D mark and =
compare reference counts =3D=3D<BR>Sun Dec 10 11:58:51 2006 =3D=3D =
eng49-3 =3D=3D mark used blocks =3D=3D<BR>processed 194314240 of =
194314240 inodes</DIV>=0A=
<DIV dir=3Dltr>Sun Dec 10 12:58:53 2006 =3D=3D eng49-3 =3D=3D compare =
used blocks =3D=3D<BR>Sun Dec 10 14:20:46 2006 =3D=3D eng49-3 =3D=3D =
processing quota trees =3D=3D<BR>processed 1 quota tree records<BR>Sun =
Dec 10 14:20:47 2006 =3D=3D eng49-3 =3D=3D mark used inodes =
=3D=3D<BR>processed 194314240 of 194314240 inodes, 16441522 of 16441522 =
directories</DIV>=0A=
<DIV dir=3Dltr>Mon Dec 11 03:58:52 2006 =3D=3D eng49-3 =3D=3D detecting =
unused quota trees =3D=3D<BR>Mon Dec 11 03:58:52 2006 =3D=3D eng49-3 =
=3D=3D processing user quotas =3D=3D<BR>processed 326040 user quota =
records</DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> Raj Kumar<BR><B>Sent:</B> Sun =
12/10/2006 11:56 AM<BR><B>To:</B> Vikas Saini; =
dl-Clio<BR><B>Subject:</B> RE: Clio R2.1 Submittal 8 - RC1 available for =
testing<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>Upgraded BC soak.<BR><BR>Started the EEK on the volume =
that we have issues in processing quotas records. Will update on the =
progress.<BR><BR><BR>-----Original Message-----<BR>From: Vikas =
Saini<BR>Sent: Sun 12/10/2006 9:44 AM<BR>To: dl-Clio<BR>Subject: Clio =
R2.1 Submittal 8 - RC1 available for testing<BR><BR>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>Perf=
orce sync info:<BR><BR>//depot/R2_1_X_work/&#8230;@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;&nb=
sp; leftover changes for changes made for defect TED00016681 and =
TED00016685.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; 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;&nbs=
p;&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;&nb=
sp;&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;&n=
bsp;&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;&nb=
sp;&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;&nbs=
p;&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;&nb=
sp; Avoid a 4k stack usage while traversing the emap =
btrees.<BR>&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&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;&n=
bsp;&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;&nbs=
p;&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;&nb=
sp; EEK should remove all the inodes sharing the duplicate =
blocks.<BR>&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&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>F=
rom: 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 "mark used inodes".<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 ("-q") 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><BR></F=
ONT></P></DIV></BODY></HTML>
------_=_NextPart_001_01C71D32.93DCB3A5--
