jeff@dsndata.uucp (Jeff Minnig) (05/11/91)
This message concerns everyone who(m) uses the ftio utility available under hp-ux 7.0 for backups and related purposes. A little history: Machine: 9000/375 OS: hp-ux 7.0 with srm/ux and april_16_scsi_patch Memory: 32MB Cluster: 13 machines + server 375 Extention: SRM/UX serving any of the above 13 clustered machines + several more. The problem: For various reasons, we had to wipe our main SCSI disk, install a minimal hp-ux 7.0 system, and then load our backup of the disk onto the minimal install system. We use our S6300.650A SCSI MO drive (not an autochanger) for backup media and write to the raw device using ftio for convience and speed. Up until now, I had extracted small groups of files off of the MO disc with no problem using ftio. When we went to restore the entire disc, ftio badly munged most of the hard file links on the disk. Made a real big mess. The message: "ftio: Out of memory. Cannot store link information" occured several hundred times. If it was out of memory, why didn't it die? The solution: The moral of this story is: If you are going to do a mass restore of anything using ftio, you need to have the 'shmbrk' variable in your kernel set to a minimum of 256 and probably higher. shmbrk controls the distance between the top of you program data area and where shared memory gets attached to the process. The default is 16 (pages) with 16 * 4KB = 64KB... Not enough memory for ftio to even spit when it has to restore ~1000 links on a filesystem. I set shmbrk to 256 ( 1MB of space ) this morning and tried to load /dev+/* onto the disk.... It correctly loaded 9 of 14 subdirectories in /dev+ before I saw the 'out of memory' problem. I then set it to 1024 ( 4MB of space ) and didn't have any problems with either /dev+/* or /usr/man/* We got bitten *badly* by this problem and I wanted to make sure that everyone who reads this group was aware of and could work around this problem. Feel free to email me with questions. Flames to /dev/null, it's been a hard week. -jeff- -- ---------------------------------------------------------------------- I said it, not the people I work for. ---------------------------------------------------------------------- Jeff Minnig | (402) 476-8278 Design Data | 1033 'O' St. Suite 324 | {hpfcla,unocss}!dsndata!jeff Lincoln NE 68508 | ---------------------------------------------------------------------- Home is where your keyboard is. ----------------------------------------------------------------------
vandys@sequent.com (Andrew Valencia) (05/11/91)
jeff@dsndata.uucp (Jeff Minnig) writes: > If you are going to do a mass restore of anything using ftio, >you need to have the 'shmbrk' variable in your kernel set to a minimum >of 256 and probably higher. When I rewrote the machine-dependent parts of HP-UX 8.0 for the VM system, this is one parameter that I cheerfully nuked. In 8.0 (unless they've changed it since, caveat emptor) the default atach point for shared memory is the beginning of the second quadrant--a gigabyte up. Same story for mapped graphic frame buffers. I suspected that it would save people a LOT of grief, and this sure looks like one of those cases! Sorry about your hard week, Andy Valencia vandys@sequent.com Disclaimer: these are my personal opinions only
franks@hpuamsa.neth.hp.com (Frank Slootweg CRC) (05/15/91)
The original poster wrote : > Machine: 9000/375 Andrew Valencia (ex-HP, now Sequent) writes : > When I rewrote the machine-dependent parts of HP-UX 8.0 for the VM > system, this is one parameter that I cheerfully nuked. In 8.0 (unless > they've changed it since, caveat emptor) the default atach point for > shared memory is the beginning of the second quadrant--a gigabyte up. ^^^^^^^^ Quadrant? Are you sure you are talking about the same machine? (i.e. 300/400 versus 600/700/800) Frank "Does 8.0 really emulate a 870 on a 320?" Slootweg, HP, Dutch Customer Response Center.
vandys@sequent.com (Andrew Valencia) (05/16/91)
franks@hpuamsa.neth.hp.com (Frank Slootweg CRC) writes: > Quadrant? Are you sure you are talking about the same machine? (i.e. >300/400 versus 600/700/800) Oops. Showing my old 300 bias :-). The 800 OS now supports sparse address spaces, too, and I seem to recall removing that tunable parameter for the 800 architecture as well. But yes, my "quadrant" comment was from the 300 world. Never mind. I'll just go back to my cubicle... Andy Valencia vandys@sequent.com Disclaimer: these are my opinions only
denny@tss.com (Denny Page) (05/18/91)
> If you are going to do a mass restore of anything using ftio, > you need to have the 'shmbrk' variable in your kernel set to a minimum > of 256 and probably higher. The default setting of shmbrk has always been a severe annoyance to applications making real use of shared memory. For our workstations, we require shmbrk > 3000, servers higher still. This problem goes away in 8.01/8.05 (at least on the 700s). Btw: Hi guys :-). Denny