Hi guys

We are urgently moving Oracle application to a backup server for some patching etc. The backup server is installed with Oracle 6.6 64Bit linux with default partitions. We found that the system has ext4 file system, while our external storage through HBA interface/IBM is formatted with ext3 file system.
Hence, please let us know what kind of performances issues we may come across, or the same could be ignored?

regards

In general ext4 performs better than ext3. Since they're in the family you can even convert ext3 to ext4 (but that takes a while).

We moved all of our Oracle stuff (Databases and Financials) to ext4 quite some time ago.

I had problems with ext4, do not migrate to it.
It was claimed "FS full" when it was 2/3 used.

So you think you had a problem, so the rest of the world should avoid ext4 ?.
Get real.

How long ago was that? There was a time in early RHEL5 where ext4 was provided as a "technology preview" and wasn't fully supported. However since then later RHEL5 as well as all versions of RHEL6 and RHEL7 fully support it. OEL is forked from RHEL.

Did you try tuning the filesystem in any way?

By default most filesystems have a reserve so won't show you 100% of space as "available" but aside from overhead most of it truly is available. You can modify the amount it reserves. Once upon a time 10% reserve was common but with multi-terabyte filesystems that is usually overkill and can be adjusted.

It was on RH 6.4.
Now I do not use it, so I have no updates about this issue, probably it already solved.

About reservation: df had shown about 75 used, reservation is above 100% of "df".

No, you can continue to use it. I will avoid. I care about my data integrity, not your.

I don't see anything like 75%

For example df shows:
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg00_atlpgpd2-lv_oracle 1008M 218M 740M 23% /oracle
/dev/mapper/VGPG2DATA-lvpostgresdb 1.5T 705G 702G 51% /database/postgresql

lvs shows:
LV VG Attr LSize
lv_oracle vg00_atlpgpd2 -wi-ao---- 1.00g
lvpostgresdb VGPG2DATA -wi-ao---- 1.47t

So the first filesystem had 1 GB (1024 MB) assigned and overhead reduced the size of the mount to 1008. Used + Avail = 958 MB.
The math shows even when with overhead (958/1024 * 100) you end up with 93% usable. If you ignore the overhead it is even higher (958/1008 * 100) at 95%.

Similarly for the large second filesystem you see of the 1.47 T (rounded to 1.5 in the df) 705 + 702 = 1407 GB. 1.47 * 1024 shows space allocated to the LV was 1505 GB and the amount available is (1407/1505 * 100) 93% with overhead.

If you were seeing only 75% it suggests something was going horribly wrong on your system OR someone set defaults using a much higher reserve.

The above are only 2 examples from the dozens of servers on which we use ext4.

If you're still using ext3 (or worse yet ext2) I'd suggest you re-explore ext4. One benefit to it we noticed right away is that deletions of large files (e.g. dbfs) would take forever on ext3 but take no time whatsoever on ext4. Also one seldom needs to wait for a full fsck of ext4 so the automated checks based on number of mounts or age can be left on. Previously with ext3 (and ext2) we had to disable the automated checks because they'd happen in the middle of reboots on major Production servers.

You might also explore going to xfs if you're truly dead set against ext4 as it has even more capabilities than ext4.

So you ran into a problem, arbitrarily blamed it on ext4, and are now spreading FUD without anything to back it up. Got it.

Morning guys

I can see that the discussion is turning in to an argument right now. Sorry for my delayed reply, as the Oracle Linux 6.6 migration proved to be a big mistake as our application server came across a number of issues like, Apache time outs, database locks etc. So I had to rollback to RHEL 5.7, so that I could be online.
We are still investigating what was wrong with the Oracle 6.6 64Bit and our version of Oracle apps R12 12.0.6

As am a newbie with Linux, I am yet to understand the differences between different file systems. Thank you all for your involvement.

regards,

You wrong here. You will end with 100% as it shown by "df" command.
Reservation (-m option for mkfs) works for root to write _more_ than 100% of FS.
This helps to make system available even /var, / , /tmp are exploding by application.
Reservation does not play any role for application FS, just wasting space.
Root have not write here and full FS does not break system down.
Therefore all application FSes I format with "-m0" option.

Ask Google: https://www.google.com/search?q=ext4+%22nospace+left%22 and read all these mystery.
I got it on $ORACLE_HOME FS, therefore Oracle just crushed.
If this will happen on ORADBS FS, this may end in data corruption.

Did you actually look at any of those? I read through a half-dozen or so, they were all solved with perfectly reasonable explanations. There were a handful of people who didn't know about root's reserved sectors (also an issue with ext3), a couple who had run out of inodes (also an issue with ext3), and somebody who was experiencing hash collision due to dir_index (can be disabled with one command).

Repeat that search using ext3 instead of ext4 and you'll get just as many matches describing the same "problems". It's just people with questions/confusion, not any indication of a bug in the FS.

This completely mystifies me. I provided the actual df output in what I wrote. The math I did was based on the difference between the underlying device file (an LV) and the resulting filesystem as shown by "df". Any overhead beyond that is NOT a function of the filesystem but rather other things (e.g. marketing capacity vs. real capacity) but is irrelevant as it isn't part of the calculation from "device file". Anything above the "device file" that took up space would be true for ANY filesystem (or even "raw" layout) you put on the "device file".

As I noted in my original post we've been using ext4 almost exclusively for the past couple of years and if it were costing us 25% of our disk array vs what ext3 did we would surely have noticed before you deigned to point it out in this thread. Also not that it matters but the OPs original post was about performance not capacity.

At this point I won't bother to respond further to you. At first I though you were just misguided and tried to give you real world information but your more recent posts suggest you just came here for an argument.

Don't worry about arguments you see online. Many technical people have differing opinions and some feel no need to sugarcoat the way they express them.

Was your 5.7 install running 32 bit or 64 bit Oracle? There can be issues with going from 32 bit to 64 bit if the binaries you're using aren't optimized for the latter as it can actually decrease performance.

You might want to run "sysctl -a" on both the original and the new system to see if there are kernel parameters that need tweaking. Usually Oracle's installation guides will suggest certain settings. Additionally you'd want to look at things like the size of the SGA vs the actual physical memory. I've seen DBAs try to create SGAs that used 99% of the memory because they'd didn't realize the OS and other associated proecesses (including some of the other Oracle binaries) might need memory of their own.

Is the Apache you had issues with the one that is installed with Oracle itself or the one that comes with the OS? Make sure you're looking at /etc/httpd.conf and conf.d for the latter and their analogues for the former.