RE: Filesystem Block Size ? 1K or 4K or 8K ?

From: Herring Dave - dherri <>
Date: Thu, 16 Oct 2008 08:39:00 -0500
Message-ID: <>

I'm finding that ASM is actually growing on me, maybe because it's letting me lazy in some areas. I don't now have x number of filesystems to spread x number of datafiles per tablespace across. I've got my one diskgroup (everything is RAID5 so no real point on having more than 1) and with ASM, OMF makes more sense to me since ASM creates it's own physical name whether you name your datafiles or not.  

This actually makes it easier from a storage standpoint for the 3 of us DBAs. Is a tablespace running out of space? Expand it's datafile until you can't (128GB with 32KB blocksize), then just add another without worrying on the specific name and placement of the datafile. ASM is smearing data across raw devices just like we would previously do with datafiles across filesystems.  

Maybe I'm way off on best practices and performance impact. I could be since ASM is relatively new to me and unfortunately I don't have the situation where I can compare apples-to-applies using filesystem to raw-ASM. If I am please do tell as we're in the process of configuring 10 new servers ranging from 8 to 23TB each.  



Dave Herring, DBA | A c x i o m M I C S / C S O

630-944-4762 office | 630-430-5988 wireless | 630-944-4989 fax

[] On Behalf Of Jared Still Sent: Wednesday, October 15, 2008 2:48 PM To:
Cc:; Greg Rahn; ORACLE-L Subject: Re: Filesystem Block Size ? 1K or 4K or 8K ?    

On Wed, Oct 15, 2008 at 6:21 AM, Dan Norris <> wrote:

If you would, please share with us your reasons to avoid ASM. Based on your response, I'm guessing that the reasons might include "because that's the way I've always done it".

Personally, I don't use it as it adds more complexity to our environment.

We (by which I really me 'I') don't need to add any more complexity.

  • Additional instance for ASM
  • file management is simpler
  • storage admins have easy direct access to see what's on disk.

I'm sure there are some rebuttals to this.

Let's hear 'em!

Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist  

The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged.

If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.

If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system.

Thank you.


Received on Thu Oct 16 2008 - 08:39:00 CDT

Original text of this message