Re: HP-UX 10.x: Where is the bad-block reserve pool kept?

In article <348439D9.B34E6204@garpac.com>, Jacob Salomon <jake@garpac.com> wrote: >(Cross-post to comp.databases.informix as well as comp.sys.hp.hpux) > >Now I have always taken the cowards way out on this one, because I don't >know where the bad-block reserve pool is kept. A bad block might be >diverted to a block that happens to be in use by the database engine. >This would kibosh my database page. Thus, I answer "no" to bad-block >relocation. The first thing that must happen to a disk is to run pvcreate (1m) on it. This establishes all of the data structures that the lv software needs to deal with the disk. The areas on a disk in order are: LIF Header (absent if disk is not bootable) Physical Volume Area (PVRA) Boot Data Reservered Area (BDRA) (absent if disk is not bootable) LIF Area (absent if disk is not bootable) Volume Group Reserved Area (VGRA) User Data Area --- this is most of the disk Bad Block Relocation Pool (BBRP) When you create a logical volume (with lvcreate (1m)), you use some or all of the User Data Area and how much you use is recorded in the VGRA. It doesn't matter whether the area will be used for swap or a file system or as a raw area for a database, everything that you allocated is available for your use. Many disks have a low level policy for handling bad blocks. The hardware, firmware and/or disk driver handle bad blocks automatically for these drives. HP calls this "hard relocation" and this is no way I know of to disable it. When hard relocation occurs the spare sectors are sectors that the disk drive keeps in reserve for this purpose. They usually reside at the end of the disk so they are actually after the "Bad Block Relocation Pool" that I show above. If a disk does not have "hard relocation", then soft relocation can be used. Soft relocation must be turned off for the root volume in order to support "Maintenance mode" booting (a way to recover if the lv structures become damaged). For other logical volumes, turning on soft relocation is a good idea. But since most disks seem to have some kind of "hard relocation" it is often a moot point. lvchange(1m) can toggle soft relocation on or off so you can still go back and turn it on for your database raw area. >What I really would like to do is answer yes, create the raw logical >volume at, say 1024 Meg, but only allocate the final 1000 meg to the >database chunk, leaving the first 24 meg as the reserve pool. (These >numbers are arbitrary.) I am assuming the reserve pool is kept at the >beginning of the logical volume. By default pvcreate creates 1 block in the BBRP for each 8K of blocks in the user data area. This is plenty...24 megs of bad blocks is way too much for a 1 gig disk. You can increase this if you really want to see pvcreate(1m). In any event you allocate the logical volume as 1000 meg, allocate all of it to the database chunk, and use the spares at the end of the physical volume as needed. Remember that the pool of bad blocks serves every logical volume that uses soft relocation on the physical volume. >Q1: Where is the reserve pool of substitute blocks really kept? > I have addressed this. >Q2: How big is each block? A 512-byte block? a 2-K sector? an 8-K > cluster? I'm not certain, but my best guess is DEV_BSIZE. Check your include files for the exact value of this if you really care. And for hard relocation, again I'm not certain, but my best guess is a sector...and sector sizes vary for each disk. diskinfo(1m) can show the sector size for each disk. >Q3: Is there a way to limit the size of the reserve pool, so that I >can be sure of a certain number of addressible blocks in the >database chunk? I have addressed this. >Q4: Does the notion of bad-block relocation even have meaning on a raw > logical volume? Yes. Paul Hite psh@access.digex.net (301)294-7364 Fresh green grass in blue-belled wood adorns the ground where snow once stood.