Unless your db_block_size is 8192 then you should use direct I/O for all Oracle file systems regardless of usage. Also because Oracle explicitly requests synchronous I/O whenever it opens its datafiles, it is the convosync mount option that counts, rather than the mincache one. Indeed, if you use convosync=direct, mincache=dsync you'll get buffering for trace files or other stuff that might also reside on your Oracle file systems, which is probably what you want.

I can't imagine any reason why you would want buffering for rollback segment datafiles, but assuming your block size is 8K there is a weak argument for buffering temporary segment datafiles. Namely that temporary segment writes are invariably read again, and operating system buffering may save physical I/O on the reads. Oracle does not normally buffer temporary tablespace I/O and so without operating system buffering there is no buffering at all. However, if your machine is dedicated to Oracle and you are willing to allow Oracle to use the memory directly, then a better approach is to use the memory that might otherwise be used for operating system buffering of temporary tablespace writes to increase the sort_area_size and thus avoid those writes entirely.

I am in the middle of a major configuration of JFS filesystem on HP-UX 11.0. I came across the follwing info.

The options you want are mount options available only with Online JFS (not a free product, unfortunately). The options you want are:

    RBS & TEMP files: mincache=dsync, convosync=dsync

    DATAFILES & REDO files: mincache=direct, convosync=direct