iwfsck run times

Hi

TS6.1 SP2 Solaris

I recently detected content store corruption and fixed this using iwfsck.

However the run of iwfsck against a 40Gb content store to a full 34 hours to complete.

Luckily we anticipated a long run time, we budgeted on 18 hours... and ran it over the weekend.

It completed successfully and we are all happy.

However "Management" are not so happy that the run took double the estimated time to complete and although we verified that the store is not corrupted, the witch hunt is on.

My previous experience is that iwfsck takes a long time to run especially with a content store of 40Gb.

Does anyone have any opinions on this?

Are there factors that add to the run time such as numbers of modified files in workareas across the system?

The numbers of branches and editions obviously adds to the processing but is there anything we can do to ease the process?

Thanks in advance.

- mark

Find more posts tagged with

Comments

Frederik

hey mark,

I'm gonna be interested by what other comments say :-)

Personally, I think that 34 hours for 40GB is lightning fast... I had some bad experiences of my own. Ok, it depends a lot on what flags you used.

I remember that on a 16GB store (ts 6.5 sp2) -d took an hour, and -d -p -r would halt after an hour for being out of memory. Then, the only solution that Support had, was using -d -p -r -s, which took 60 DAYS :eek: :eek: (cfr earlier post)

(actually, the 60 days is a projection, because we stopped the process after 40 days, but we could estimate from the logging how much more still needed to be checked. This was on a copy of the store - we didn't have our endusers waiting for that time Smiley Wink

)

Do you have like 100GB of RAM on that machine?

Support also claimed that if you have a store that was originally started in TS 5.5.2 (or TS 6.0 or TS 6.1) and then continued to be used in TS 6.5, you had a risk of instability and slower performance on iwfsck. The solution is to start with a fresh backing store, possibly populated via iwmigrate or a home-brewn import step. There's a KB article 55361 to that effect.

Oh, do you occasionally run iwfsshrink... It can reduce the store size a bit, and probably that helps iwfsck times too.

--Fred

mmb

hey mark,

I'm gonna be interested by what other comments say :-)

Personally, I think that 34 hours for 40GB is lightning fast... I had some bad experiences of my own. Ok, it depends a lot on what flags you used.

I remember that on a 16GB store (ts 6.5 sp2) -d took an hour, and -d -p -r would halt after an hour for being out of memory. Then, the only solution that Support had, was using -d -p -r -s, which took 60 DAYS :eek: :eek: (cfr earlier post)

(actually, the 60 days is a projection, because we stopped the process after 40 days, but we could estimate from the logging how much more still needed to be checked. This was on a copy of the store - we didn't have our endusers waiting for that time )

Do you have like 100GB of RAM on that machine?

Support also claimed that if you have a store that was originally started in TS 5.5.2 (or TS 6.0 or TS 6.1) and then continued to be used in TS 6.5, you had a risk of instability and slower performance on iwfsck. The solution is to start with a fresh backing store, possibly populated via iwmigrate or a home-brewn import step. There's a KB article 55361 to that effect.

Oh, do you occasionally run iwfsshrink... It can reduce the store size a bit, and probably that helps iwfsck times too.

--Fred

Fred

Thanks for your reply.

Well that makes me feel slightly better!!

We ran iwfck -d -y

We only have 4Gb RAM on the server that ran it... so I guess we got off lightly there in terms of processing time!

We regularly run iwfsshrink to claw back disk when we need to so that may have helped.

I will feedback the 60 days to see the reaction..!

thanks
- mark

msrinivas

I had someone run iwfsck -d for me on a TS 5.5.2 store of 145GB and it took only 4 hours :eek:

I was VERY surprised myself. I guess it very much depends on how you handle your store w.r.t file submits etc. I am assuming irrespective of the store size its the store structure that matters.

Adam Stoller

Fred

Thanks for your reply.

Well that makes me feel slightly better!!

We ran iwfck -d -y

We only have 4Gb RAM on the server that ran it... so I guess we got off lightly there in terms of processing time!

We regularly run iwfsshrink to claw back disk when we need to so that may have helped.

I will feedback the 60 days to see the reaction..!

thanks
- mark

FWIW - it is highly recommended against using the -y flag when running iwfsck because not all automated fixes are "correct".

The process I've always used in the past is: