Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!sparky!dsndata!jeff From: jeff@dsndata.uucp (Jeff Minnig) Newsgroups: comp.sys.hp Subject: BEWARE ftio(1) caveat Message-ID: Date: 10 May 91 18:25:42 GMT Sender: jeff@dsndata.UUCP Distribution: comp Organization: Design Data Lines: 78 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. ----------------------------------------------------------------------