filesystem sizes

[sheevm]

Hi All,

What is the advantage/disadvantage of making the filesystem larger/smaller? Are there any documents available on this subject? We are currently running 11.23, rp8420

Thanks
Raji

[A. Clay Stephenson]

This question has almost no meaning without some context. The most critical filesystems not to size too small are those that can't be
increased in size later because they must be contiguously allocated. /stand are /root are the obvious examples for this constraint. In those cases, anything over 2X the minimum size is overkill --- and these are normally small filesystems anyway. From a performance perspective there is no disadvantage to a large vxfs filesystem --- as long as large means lots of capacity rather than lots of files in a few directories. The biggest performance hits are going to occur when someone uses a filesystem tree as a substitute for a database rather than a dedicated database. If you have to look for specific files among hundreds of thousands of entries there is a performance penalty to be paid. The other consideration is that normally it is better to spread i/o over as many separate data paths as possible but with moderm cache-centric Fibre-connected arrays even this is not a terribly important point.

If you have OnlineJFS (and you should) then it's so easy to resize filesystems later (other than those which must be contiguously allocated) that it is really not worth worrying about.

Now, if you can ask a more focused question then perhaps a more focused answer is possible.

[sheevm]

Hi,

The more focused question is:

We have RAID 1/0 SAN disks allocated to the Oracle database servers. The allocated disk space is about 90GB with one volume group for oracle databse files.

Are there any advantage of splitting the database files across several small mount points versus creating one filesystem with 90GB?

Thanks

[spex · Accepted solution]

Raji,

You might want to create separate LVs and mountpoints to provide disaster isolation. For example, suppose you have two datafile mountpoints, /u01 and /u02, and that the Oracle RDBMS is shutdown.

# rm -rf /u01

Now everything in /u01 is gone, but /u02 is unaffected. Admittedly, this is a contrived example, but it does illustrate the principle.

Personally, I would split the 90GB into a few LVs, but leaving it whole would also be fine.

PCS

[A. Clay Stephenson]

For modern SAN's the performance differences will be all but extremely difficult to measure in most cases.

It never hurts to divide the i/o into as many LUN's as you have separate data paths for but nowadays that tends to make very little difference.

One dubious advantage of many LUN's is that it makes performance APPEAR better to host-based performance tools like Glance. With only a 1 or 2 LUN's, all Glance can know is that a herd of i/o is going through what it sees as one physical disk -- nevermind that this one "disk" is actually composed of 10 physical disks within the array.

[James R. Ferguson]

Hi Raji:

> Are there any advantage of splitting the database files across several small mount points versus creating one filesystem with 90GB?

Yes, absolutely there is an advantage to doing this. Large or small filesystems aside, using separate filesystems (mountpoints) enable you to leverage JFS (VxFS) mount options to optimize performance (buffer caching or not)! See the manpages for 'mount_vxfs' for more information along with this whitepaper:

http://docs.hp.com/en/5576/JFS_Tuning.pdf

Regards!

...JRF...