[Ocfs2-users] Filesystem Block Size w// DB_BLOCK_SIZE

[Karim Alkhayer]

Folks,

We're using two "StoreWay FDA" storage with around 5 TB on each. 
The connection from the servers to the storage is through fiber channel
RAID 6 is used with 7400RPM for non-index data files whereas 10K RPM is for
the indices
ASM is not used, the tablespaces are sized and organized based on the
business requirements

The platform provider is a hesitating to upgrade SLES from SP3 to SP4, so
that we can benefit from the latest possible version of OCFS2. Therefore,
any potential enhancement for the current scenario would be the best chance
for now

Appreciate your thoughts

Cheers,
Karim


-----Original Message-----
From: Sunil Mushran [mailto:sunil.mushran at oracle.com] 
Sent: Friday, December 19, 2008 11:57 PM
To: Karim Alkhayer
Cc: lfreitas34 at yahoo.com; ocfs2-users at oss.oracle.com
Subject: Re: [Ocfs2-users] Filesystem Block Size w// DB_BLOCK_SIZE

True.

The only point I would like to add is that you are using a 2+ yr
old version of the fs. You should upgrade to atleast SLES9 SP4.

Luis Freitas wrote:
> Karim,
>
>   This is not OCFS2 related, it is more related to the disk hardware
capabilities and how it works.
>
>   That will depend on your OS, HBAs and storage, and the workload.
>
>   There is a maximum queue depth associated with each LUN, so if you use
several LUNs on the same device, you could achieve more outstanding scsi
commands open on the controller. But each port will also have a maximum
queue depth that cannot be excedeed, so at some point using extra LUNs wont
give you this advantage.
>
>   If the storage/disk have more outstanding requests it could provide a
better performance by reordering them to provide a larger overall
throughput, given that the storage hardware supports this. Probably it
supports it, since even low end SATA disks supports reordering nowadays.
>
>   On the other hand the database (Or ASM for that matter) has no ideia
that these luns are from the same device, so it will spread the data evenly
accross them, and your data will end up scattered accross the disk, instead
of concentrated at the start of the disks. This will bring a performance
penalty, most noticeable on full table scan operations since they read the
data sequentially from the start to the end. If you tune the tables extent
size you can work around this problem.
>
> Regards,
> Luis
>
> --- On Thu, 12/18/08, Karim Alkhayer <kkhayer at gmail.com> wrote:
>   
>> From: Karim Alkhayer <kkhayer at gmail.com>
>> Subject: [Ocfs2-users] Filesystem Block Size w// DB_BLOCK_SIZE
>> To: ocfs2-users at oss.oracle.com
>> Date: Thursday, December 18, 2008, 9:20 PM
>> Hello All,
>>
>> We're hosting DB1 and DB2  with db_block_size  set to 
>> 8K, 16K respectively
>>
>> File system creation is done with mkfs.ocfs2 -b 4K -C 32K
>> -N 4 -L   LABLE
>> /dev/mapper/xxxx
>>
>> Mount is done with:  ocfs2  _netdev,datavolume,nointr 0 0
>>
>> I'd like to know if we can separate most of the
>> tablespaces on different
>> LUNs, even if they're on the same disk group sometimes,
>> is it possible to
>> gain better performance? Is the impact limited to the time
>> of creating the
>> tablespaces only (assuming they're pre-sized properly)?
>>
>> Current OCFS2 version is 1.2.1
>>
>> Current OCFS2 components:
>> ocfs2-tools-1.1.4-0.5
>> ocfs2console-1.1.4-0.5
>>
>> # uname -r
>> Kernel 2.6.5-7.257-default
>>
>> # cat /etc/SuSE-release
>> SUSE LINUX Enterprise Server 9 (ia64) VERSION = 9
>> PATCHLEVEL = 3
>>
>> Oracle 10.1.0.5
>>
>> Appreciate your input 
>>
>> Best regards,
>>
>> Karim
>>