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

[Karim Alkhayer]

Hi Luis,

> We're already running 2.6.5-7.257-default (SP3 has .244)
> What is updatable in my view is kernel 2.6.5-7.283.ia64. this kernel ships
with
> OCFS2 1.2.3. So, we'll be upgrading from 1.2.1
> Question here is how much gain in such scenario?

Best regards,
Karim





-----Original Message-----
From: Luis Freitas [mailto:lfreitas34 at yahoo.com] 
Sent: Saturday, December 20, 2008 3:30 PM
To: Karim Alkhayer
Cc: ocfs2-users at oss.oracle.com
Subject: RE: [Ocfs2-users] Filesystem Block Size w// DB_BLOCK_SIZE

Karim,

   Even if they wont upgrade the entire system, I see no reason to not
upgrade the kernel.

   On Suse, upgrading the kernel would upgrade the OCFS2 version that is
being used. And if there is trouble you could revert to the older kernel.

Regards,
Luis


--- On Sat, 12/20/08, Karim Alkhayer <kkhayer at gmail.com> wrote:

> From: Karim Alkhayer <kkhayer at gmail.com>
> Subject: RE: [Ocfs2-users] Filesystem Block Size w// DB_BLOCK_SIZE
> To: "'Sunil Mushran'" <sunil.mushran at oracle.com>
> Cc: lfreitas34 at yahoo.com, ocfs2-users at oss.oracle.com
> Date: Saturday, December 20, 2008, 8:57 AM
> 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
> >>