Some folks just don't want to listen to reason.
Here is a pdf concerning raid and defrag
http://www.raxco.com/products/perfec...rs/pd_raid.pdf
"bob" wrote:
> raid 0+1 (3 drives stripe set, mirrored) with 4k default cluster size.
This concerns me since 0+1 would be 4 drives minimum. My 0+1 is 6 drives
with one hot spare. Hot spare is VERY important in 0+1 since the loss of a
single drive reduces the raid level to 0.
See here
http://www.acnc.com/04_01_0_1.html
Might want to look at the array and its configuration. Ideally you split
this across two channels thereby reducing the bus contention between
different disk requests. I use two channel raid cards for this.
Here is something on database block size
http://www.ixora.com.au/tips/block_size.htm
MS SQL recommendation for 16K blocks
http://www.ctlcorp.com/support/sql/admin.html
though it looks like with MS SQL 8k is default
http://www.wilsonmar.com/1sql.htm
Here is some more page size advice
http://www.sleepycat.com/docs/gsg/C/...pagesizeAdvice
From my Google read I get that with databases you can use larger pages
depending on the database manufacturer. It really is a simple matter of
math. If you know what the block size that is being written then you know an
even increment of that number will be a good disk block size. It is also
clear that if you have a 32K write that 4K blocks means 8 writes and most
likely not contiguous. Whereas that same write to a 32K disk block is a
single write. It doesn't take a rocket scientist to figure out which is
faster: 8 writes vs. 1 write.
It appears to be that you can adjust the page size used by the database and
then match that with the disk block size from my reads but I can't find the
magic number. The magic number is in what increments is the disk written to.
For example Ms page file ops in memory is done in 4K increments. But when
writing from memory to the disk it’s done in 64K increments. So 64K blocks
are ideal for page file operations and not 4K ones