topic Re: Normal for /sbin/bcheckrc to take long time at boot? in Operating System - HP-UX

Normal for /sbin/bcheckrc to take long time at boot?

Mike Keys — Tue, 16 Aug 2005 08:37:12 GMT

We recently migrated some of our databases running on a local 12H array to an EMC SAN (CX500). The servers are N4000's. The thing that I notice now is the boot time has slowed dramatically.

During boot, I see the echo for EMC PowerPath starting. The next echo is: /sbin/bcheckrc

I understand this script is going through each filesystem and running fsck and making sure that it is clean and then activating the volume group. vg00 is usually activated within 1 minute. However, the SAN volume groups typically take anywhere from 4 to 6 minutes a piece before they are activated. This his tacked on about 15 - 20 minutes extra to my boot time.

Is there any way to shorten the amount of time that the bcheckrc script takes to run?

Re: Normal for /sbin/bcheckrc to take long time at boot?

Florian Heigl (new acc) — Tue, 16 Aug 2005 08:55:13 GMT

This is 'a bit' longer than it usually takes.

There is a certain delay for activating SAN volume groups, as a rough number a larger database host might take 2 minutes for 10 VGs with ~60 LUNs.

I've also seen it take much longer, to the extent of 25 minutes, but in this case we had some definite problems.

some steps You should take:
- check
/opt/fcms/bin/tdutil /dev/td stat
output, looking for transmission errors
- get both CX service processor logs for excessive trespassing (this will only show up as informational, but it may rise to levels above 1000/minute, which will influence the array in a *bad* way)
You can aquire the SP logs either via the java navisphere thing or using
/opt/Navisphere/bin/navicli -h getlog.
- check Your kernel setting FCP_MAX_REQUESTS - it defaults to 512 requests per adapter per second, which maybe more than EMC^2 supports - ask them and adjust the value (in our case this definitely solved the issue)

In short: Either a hardware or a configuration issue.
If allowable, I'd ask You to post the fcms and sp logs.

Re: Normal for /sbin/bcheckrc to take long time at boot?

Steven E. Protter — Tue, 16 Aug 2005 09:13:00 GMT

Seems a bit slow. I'd get the SAN side looked at.

Also, ioscan fnC disk see if there is a problem with alternate paths and such.

SEP

Re: Normal for /sbin/bcheckrc to take long time at boot?

Devender Khatana — Wed, 17 Aug 2005 00:00:35 GMT

Hi Mike,

Allthough we do not have VG's on SAN but have VxVM DGs. The DG activation time reduced dramatically when we updraded VxVM to 3.5 from 3.2 last year. We use XP array 1024 & 512.

I would also suggest to look for latest patches and also try to activating VG manually after system is up. This can be done by changing auto activation parameter for non-root vg's in /etc/lvmrc file.

AUTO_VG_ACTIVATE=0 ( For preventing auto activation)

HTH,
Devender

Re: Normal for /sbin/bcheckrc to take long time at boot?

Mike Keys — Wed, 17 Aug 2005 09:37:37 GMT

swlist -i shows:

Base-VXVM -> B.03.50.5 on all servers with VG's on SAN.

Re: Normal for /sbin/bcheckrc to take long time at boot?

Simon Hargrave — Wed, 17 Aug 2005 09:43:55 GMT

I would have a look at your bcheckrc file. It is not uncommon for this to be amended on-site to force a FULL fsck on each filesystem, regardless of the clean flag on the filesystem. This can cause your system to take longer to boot.

Re: Normal for /sbin/bcheckrc to take long time at boot?

Mike Keys — Wed, 17 Aug 2005 09:52:07 GMT

Even though the script says not to modify, what should I be looking at in the script?

Re: Normal for /sbin/bcheckrc to take long time at boot?

Florian Heigl (new acc) — Wed, 17 Aug 2005 10:48:24 GMT

One more possible reason that just came to my mind would be seeing too many (foreign) luns. (i.e. improper storagegroup configuration)

Re: Normal for /sbin/bcheckrc to take long time at boot?

Mark Fisher_4 — Sun, 28 Aug 2005 09:55:41 GMT

I have been battleing the exact same problem on newly installed equipment since last May. VG activation of EMC DX500/DX700 luns is very slow. EMC came out with a patch for Powerpath, 4.3.1.2, but it did not resolve the issue for me. Many other HP/UX customers are reporting the same issue. I would log a ticket with EMC so we can turn up the heat on them and het this fixed.