Files not starting on swidth

[The Levinson Family <levinson.h@xxxxxxxxxxx>]

We are using Suse SLES 9 SP2 (soon to upgrade to SP3) for a DB2 database 
platform on an AMD64 dual cpu server.  Each server has two 256GB 
partitions mounted from a clariion storage array. The clariion luns are 
each a RAID 5 array with 64KByte stripe units x 4 data disks for a 
256KByte stripe width.  The xfs filesystems look like

# xfs_info /dev/emcpowera1
meta-data=/mnt/db02-01           isize=256    agcount=16, agsize=4365040
blks
        =                       sectsz=512
data     =                       bsize=4096   blocks=69840576,
imaxpct=25
        =                       sunit=16     swidth=64 blks,
unwritten=1
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=32768, version=1
        =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0


I think we will adjust sunit setting on logs to match the sunit setting 
of the rest of the filesystem.

When DB2 creates containers for the tables, I notice two things. First 
is that files don't start on swidth boundaries. They don't seem to match 
up to even an sunit boundary, but I should double check that.  Do I need 
to preallocate with xfs_io to get files to line up on swidth boundaries?

What does the offset argument to resvsp control? I didn't see it 
described in the man page and the reference to xfs(5) didn't have any 
details either.

Should I be using the realtime section for these files to get minium 
extents of swidth for the large container files or is there a way to 
enforce extent size in the normal data section?

The DBA's like to create parallel containers instead of one container. 
When this is done, sets of database blocks (extents in their terms) are 
striped across the various container files.  For this to work, each 
write needs to in the same order that the database issued. Unfortunately 
the files are thrown all over. Is this a side effect of the allocation 
groups?  If so, and we changed to one allocation group (if possible) how 
much would that effect performance.

I saw a note on the list about a new feature that would assign 
allocation groups to directories. Would this help them with the write 
order of these striped containers, if all striped containers for a 
tablespace were under a single directory? My ultimate goal is to get 
them away from striped containers and use one big one.

   thanks
   harry levinson