EXT4 File System @ Server side & Ext3 external storage

voleg · 05-28-2015, 12:39 PM

Code:

# lvcreate -L1g -n test /dev/rootvg
# mkfs.ext3 -j -m30 /dev/rootvg/test
# mount /dev/rootvg/test /mnt/test
# df /mnt/test
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/rootvg-test  976M  1.3M  668M   1% /mnt/test
$ dd if=/dev/zero of=/mnt/test/file bs=1024k
$ df /mnt/test
/dev/mapper/rootvg-test   976M  669M     0 100% /mnt/test

As you see, "df" show 100% usage despite reservation. (not 70%)

I agree, it is enough for this stupid dispute. I hope you will never hit the bug I saw in ext4.
I prefer you will think me stupid paranoid, then lose your data.

MensaWater · 05-28-2015, 01:35 PM

I really shouldn't bite again but I can't resist because this is so laughable.

The funny thing is what you just did was ext3 NOT ext4!

This would seem to blow your original argument that ext4 is the problem out of the water.

Do you really not understand why an LV of "1g" is full when you try to create a "1024K" file on top of the filesystem created on the LV?

My guess is your dd failed rather than completing and you didn't notice. What I DID notice is you didn't provide the output so we can't tell whether it failed or not but math suggests it did. You also didn't give ls output for the resulting file.

An aborted write can leave the inode in use even if the file is "deleted". A common issue seen on all filesystems in both UNIX and Linux is when a user deletes a file (e.g. a logfile) that is still being held "open" by a process. This is because that leaves the inode (and thus the space) in use even though the file name no longer appears in ls output. That is to say the filename was the only thing deleted in such a case. One can clear the space by stopping/killing the process that had the file "open". A lot of folks will do this by rebooting but with lsof one can actually determine the process and avoid a full reboot.\

By the way:
669/976*100
68.54508196721311475400 - That's close enough to 70% for my money. The rest of the "100%" you're seeing IS the reserve YOU specified in the mkfs.ext3 you ran.

rajthampi · 06-01-2015, 06:12 AM

Quote:

Originally Posted by MensaWater

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.

Once again, am late with my replies. We had a nasty issue with the air conditioning and the TEST server had OS level issues. Let me answer your questions one after another

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.

=> We were always on 64 bit, hence the OS architecture was not the issue

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.

=> We have followed the Oracle suggestions for the kernel parameter settings (replicated over both Target and Source systems)

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.

=> This could be a real issue, I mean while we installed the OS afresh over the new target system, we chose the web server as an additional component.

Anyway, I rebuilt the OS, configured the kernel parameters, limits, and resolv files & the performance is much satisfactory. Still monitoring and if there is anything interesting coming up, will post

regards,