From: Naylor, Jim (Jnaylor@Schnucks.com)
Date: Tue Jul 23 2002 - 08:47:53 EDT
Thanks to Wolf-Dietrich Schmook, Bill Hassell, Eef Hartman, and Raj Mannar
for their helpful responses listed below:
Wolf-Dietrich Schmook:
the line about "bsize" in the output of tools like "fstyp -v" is totally
useless
for a VxFS - it doesn't even change when you use a different block size :-(
And the whole point oracle tries to make is to make sure that an
oracle-block is
NOT stored split into multiple places on the disk (causing head-movements,
slowing down oracle).
Actually on a VxFS the files are organized (and allocated on disk) in
"extents"
(like in oracle), and a single "extent" can be up to the size of a single
"allocation unit" (which usually is 32MB, each!). I am talking about
pre-allocated files, not Windows-like slowly growing ones...
So, every block-size of a VxFs works fine for oracle data file systems.
Bill Hassell:
Studies have shown that there is very little performance advantage
trying to match Oracle's block size with the filesystem block size
on HP-UX. First, ignore the frag size since it has virtually no
meaning on VxFS filesystems. Second, the actual physical writes are
in multiple blocks, up to 128k or more, depending on the circumstances.
Because all the writes will go through the buffer cache, blocksizes
at Oracle's level are masked by the buffer cache handling.
The only important factor is to have the filesystem's blocksize an
even multiple of Oracle's, so 8k is fine. You may find that having
a VxFS filesystem blocksize of 16k may be slightly better but it
very dependent on the access methods, which in turn depend on the
DBA's settings and which files you are working with. Oracle has
several distinct and very different directories, the data directories
(a few very large files), the rollback and archive files (very busy
with writes, a temp sort area (if you don't have enough memory),
and so on. Each should be on a separate controller or at least a
separate disk.
Save yourself a lot of time by concentrating on getting the high
rate filesystems moved to other channels, and of course, looking at
SQL plans that are extremely inefficient.
Eef Hartman:
8 KB, of course. As far as I know that is the ONLY blocksize the VxFS file
system supports on logical volumes of that size.
Raj Mannar:
f_frsize *IS* the block size. So, in your case, the
filesystem did get created with 4K block size. I know, it is
confusing, but fragment size is the actual block size.
Also, by default, vxfs creates 1K block size and not 8k block
size. You can test it by creating a test filesystem without
giving -b option. (man on newfs_vxfs and see the -b option.
It says default for -b is 1024).
Once again, Thanks to all,
Jim Naylor
Unix Systems Administrator
Schnuck Markets, Inc.
314-994-4784
jnaylor@schnucks.com
-----Original Message-----
From: Naylor, Jim
Sent: Thursday, July 18, 2002 1:43 PM
To: Hpux-Admin@Dutchworks. Nl (E-mail)
Subject: [HPADM] newfs -b option
Good Day All,
According to Oracle the Oracle block size can be set to 4k, 8k, 16k, or 32k.
They suggest that the Unix filesystem block size be set to the same. The
default filesystem block size for HP-UX 11.0 is 8K. I have a Oracle
instance that is 4K and I need to create a filesystem with a block size of
4K. I have a logical volume created and am trying to create the filesystem
with a block size of 4k using the following command:
newfs -F vxfs -o largefiles -b 4096 /dev/vgxxx/rlvxxx
This gives me the following output but tells me it is created at a blocksize
of 4096:
# newfs -F vxfs -o largefiles -b 4096 /dev/vgora_itemM/rlvora_itemM
vxfs mkfs: It is advisable to have block size of 8192 or larger
vxfs mkfs: for file systems greater than 42GB
version 3 layout
44146688 sectors, 11036672 blocks of size 4096, log size 512 blocks
unlimited inodes, 11036672 data blocks, 11035368 free data blocks
337 allocation units of 32768 blocks, 32768 data blocks
last allocation unit has 26624 data blocks
first allocation unit starts at block 0
overhead per allocation unit is 0 blocks
When I do a df -g /mountpoint it shows the following:
# df -g /oracle/rdbms/itemM
/oracle/rdbms/itemM (/dev/vgora_itemM/lvora_itemM) :
8192 file system block size 4096 fragment size
11036672 total blocks 11035449 total free blocks
10863022 allocated free blocks 2758864 total i-nodes
2758860 total free i-nodes 2758860 allocated free
i-nodes
1075249153 file system id vxfs file system type
0x10 flags 255 file system name
length
/oracle/rdbms/itemM file system specific string
This tells me the file system block size is 8192 and the fragment size is
4096.
If I do a fstyp -v /dev/vgora_itemM/lvora_itemM I get the following:
# fstyp -v /dev/vgora_itemM/lvora_itemM
vxfs
version: 3
f_bsize: 8192
f_frsize: 4096
f_blocks: 11036672
f_bfree: 11035449
f_bavail: 10863021
f_files: 2758880
f_ffree: 2758848
f_favail: 2758848
f_fsid: 1075249153
f_basetype: vxfs
f_namemax: 254
f_magic: a501fcf5
f_featurebits: 0
f_flag: 16
f_fsindex: 6
f_size: 11036672
This also tells me the filesystem blocksize is 8192 and the filesystem
fragment size is 4096.
So can anyone tell me what is my actual filesystem block size is?
Thanks,
Jim Naylor
Unix Systems Administrator
Schnuck Markets, Inc.
* Direct: (314) 994-4784
*)) Cell: (314) 691-0186
* Fax : (314) 994-4684
* jnaylor@schnucks.com
--
---> Please post QUESTIONS and SUMMARIES only!! <---
To subscribe/unsubscribe to this list, contact
majordomo@dutchworks.nl
Name: hpux-admin@dutchworks.nl Owner:
owner-hpux-admin@dutchworks.nl
Archives: ftp.dutchworks.nl:/pub/digests/hpux-admin (FTP, browse
only)
http://www.dutchworks.nl/htbin/hpsysadmin (Web, browse &
search)
--
---> Please post QUESTIONS and SUMMARIES only!! <---
To subscribe/unsubscribe to this list, contact majordomo@dutchworks.nl
Name: hpux-admin@dutchworks.nl Owner: owner-hpux-admin@dutchworks.nl
Archives: ftp.dutchworks.nl:/pub/digests/hpux-admin (FTP, browse only)
http://www.dutchworks.nl/htbin/hpsysadmin (Web, browse & search)
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 11:02:16 EDT