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

[Mike Keys]

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?

[Florian Heigl (new acc)]

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.

[Steven E. Protter]

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

[Devender Khatana]

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

[Mike Keys]

swlist -i shows:

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

[Simon Hargrave]

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.

[Mike Keys]

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

[Florian Heigl (new acc)]

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

[Mark Fisher_4]

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.