I totally agree over the performance issues. JFS is built over the top of LVM,
so using RAW volumes directly completely eliminates one complete layer of
complexity.

Head movement optimisation should be done in the stratedgy layer of the
physical disk driver (the one just above the ones directly dealing with the
hardware). I have not looked at the AIX source recently (and since I no longer
work with IBM, I probably will never have the chance again) but certainly the
code IBM took from Unix SVR2 implemented the elevator algorithm for disk
accesses.

On the subject of JFSconsistancy, remember that JFS just protects the control
structures of the file system itself, not the data. This prevents such things
as the system allocating space to a file, but not removing the space from the
free block map. It does not journel writes to ordinary files. The original
idea was to reduce the number of times it would be necessary to fsck
filesystems should the operating system crash. It is very good at this, but
does not allow applications to perform full rollback journeling on multi write
trancactions. Database files can still be corrupted.

Peter Gathercole
Open Systems Consultant.

Bruce Elrick wrote:

> Brown, Ed wrote:
> >
> > I tend to agree with this point.....
> >
> > > Raw vs JFS is an interesting issue.  Up until now I've gone RAW (on
> > > everything)
> > > since it is quicker to setup and is higher performance.  Now however I
> > > have been
> > > informed that database corruption can occur if a second server
> > > instance is started
> > > (no mention of storage pool space but it would appear to be subject to
> > > the same
> > > problem).
> > >
> > > Furthermore, according to an internal but third party source, AIX RAW
> > > device code is
> > > not being improved while JFS performance is.
> > > Now I'm leaning toward JFS
> > >
> > This is very interesting, and it seems to make sense. I sounds similar
> > to the thought
> > of putting highly accessed files toward the center of the disk for
> > highest average
> > access.
> >
>
> Improving the performance of JFS only lowers the overhead that JFS adds
> on top of the LVM.  That is, the JFS has the same LVM overhead beneath
> it as any application that uses raw logical volumes.  Perhaps the JFS
> could re-arrange write order more intelligently than an application
> (ADSM) to take advantage of variation in disk readiness, using the
> journalling to ensure data integrity with asynchronous writes, but I'm
> not sure it actually runs that way.  ADSM probably wants to assume
> synchronous writes for its own data integrity (i.e. if it writes block X
> before Y, it assumes that in the event of a crash where not all data is
> written to disk, there is never the case where block Y was written when
> X wasn't).  At least that should apply to mirror copies of the log when
> sequential writes are chosen.
>
> With respect to corruption with a second server, should not the locking
> of access to JFS files be the same as locking of access to the device
> special files that an application opens to access the raw logical
> volumes?  That is the whole point of accessing character-mode devices
> through the filesystem; you can treat it like a file, for the most part.
>
> One advantage of having a JFS is protection from system crashes
> corrupting the log and database.  ADSM is currently vulnerable to
> (some?) partial page write problems which JFS would presumably lower the
> chances of occuring relative to raw since it is journaled.
>
> Anyone who understands the details care to correct my ramblings?
>
> Cheers...
> Bruce