> We haven't installed VM yet. The Linux test LPAR has 512MB of
> memory, of
> which over 480MB is shown as the buffer, crippling the system.

This is actually normal behavior -- if the RAM is unused for other
purposes, it gets used for disk buffers. I don't think this is the root
cause of the problem -- something else is happening that is causing your
LPAR to croak. Unfortunately, since you're running in LPAR, short of
single-stepping the LPAR from the HW console, it's almost impossible to
determine what is causing the problem w/o editing a lot of stuff in the
startup scripts which you'd have to go back and undo later.

> Would you know how FSCK works ?

fsck is the equivalent of MS-DOS's "scandisk.exe".  It verifies the
integrity of the internal structures in the filesystem and can
optionally repair most minor (and some major) inconsistencies. It
operates on individual blocks, and usually (depending on the
architecture and OS) does not buffer I/O as it tends to be working on
things that would be really, really unhappy if the updates were not
atomic and guaranteed.

> Is it supposed to allocate
> and free the
> buffer space for the file system ?

No. fsck is a repair and verification tool. It has no control over
buffering or buffer allocation policy.

> Would you recommend that
> we run FSCK
> regularly ?

No. Like any useful power tool, it can maim as well as heal. Use manual
fsck's only when necessary. You can do serious harm with fsck if you use
it casually.

>  Is there a way to force the system to free the buffer ?

The 'sync' command forces the system to flush the contents of buffers to
disk, but given that you are using the 2.2-based 7.0 kernel, you have
little or no control over memory allocations to buffers.  You could
potentially write to kernel memory to try to trigger a flush, but this
is NOT recommended. Your gun, your foot, your restore from tape...8-(

You may also want to verify that you have the most recent LVM code.
There are some behavior enhancements that reduce the amount of I/O done
to identify VGs at boot in recent releases.  Again, since you are
running very old kernel code, you may need to do some tinkering to make
the current LVM code work properly.

FWIW, I'd recommend concentrating on installing VM rather than spending
time with Linux in LPAR. You'll avoid wasting a lot of time on these
issues, and you'll have a much more useful system as a result.

--d b

Reply via email to