>           back again with the discusssion. I searched for info regarding raw
> volumes. There appears to be a viewpoint that raw volumes might not
> necessarily improve the read/write speed. primarily because even though JFS
> has its overheads, It has also the buffering mechanism. However we could
> benefit from file system fragmentation limitations on AIX.

I would try it and see what happens.

Try to design a bench mark test, measure a transfer rates and
utilisation in both cases, then compare.

My experiences were that raw volumes rattled less [lower utlisation
rates for the same thru-put] than cooked volumes.  I am comfortable
with raw volumes, so stuck with that.


The case for raw volumes is normally

you bypass the buffering and double copying inside the OS.  On
Solaris, ADSM server uses mmap, so this is minimised.  I have no idea
about AIX and how the VM subsystem and the IO subsystems interact.


if you put multiple ADSM volumes defined on a single logical JFS
volume you will causing contention on the disk(s).  ADSM round robins
between volumes in a storage pool during a backup.



The application does not require the services of a file system: ADSM
or a database organises its information inside large files, so there
is no point in having the file system in the way.


The application has an idea of where it wants to put data inside
that single large file.  The file system also has an idea of where
things should be put.  It is easy to see them treading on each other's
toes.


Data intergrity.  Traditionally, the coupling between the UNIX OS
and the physical media was not tight enough to guaratee intergrity if
the system crashed or was powered off mid write.  Raw disk did.

Async IO with completion call backs now eliminates that as a problem.
At least that is how DEC pitched the Async I/O features of DEC UNIX
when they "invented" it :-) :-)


Some of those arguments apply to ADSM.

Russell