[comp.sys.hp] BEWARE ftio

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