Re: FRA f/s block size

From: Noons <>
Date: Tue, 29 Mar 2011 19:47:37 +1100
Message-ID: <ims6b7$5qh$>

joel garry wrote,on my timestamp of 29/03/2011 3:55 AM:

>> I've got my development node with an FRA file system with 512 byte
>> block size.
>> And production is on 4096 - max for jfs2.
>> I haven't been able to prove conclusively that one is better than the
>> other for
>> normal RMAN backup/restore operations.
>> Any accumulated wisdom/advice/experience on this?
>> Nope: I couldn't find a button for this in OEM or grid, either...
> The docs seem to say Oracle uses different size buffers depending on
> your multiplexing
> but I would guess the OS characteristics would have a greater effect.

Yup, makes sense.

> Is AIX strange?

Man, is it ever! Weirdest Unix I've ever seen. And I don't mean that in a bad way:
there's a lot of good stuff about Aix and Power6.

> I'd speculate you could force a visible effect doing
> something like restoring a whole bunch of single blocks with Oracle
> using a small buffer and the OS using a large one, getting lots of
> extra unnecessary blocks from the OS to discard. Everything else
> would likely mask effects because you are streaming lots of blocks
> sequentially, no? Well, maybe if you are blasting out lots of blocks
> onto a device with heavily hit random access data files...

My guess is that jfs2 and/or Oracle will stream together a lot of small I/Os into a scatter/gather type operation that won't be much affected by the file system blocksize. As such it won't matter much if I got 512 or 4096, performance-wise. Except for the last I/O in a stream, and that won't be much overall anyway. Provided as you say I'm not colliding with other types of I/O.   Which I'm not: this f/s is dedicated to FRA, on its own SAN LUN. Likely as well why I am not seeing any differences between 512 and 4096?

Still: all speculation. I'll try and strace something to see if I can figure out what the heck is going on at the coal face. Will report back here. Received on Tue Mar 29 2011 - 03:47:37 CDT

Original text of this message