Filesystems wont mount even though they are in fstab

[Rita C Workman]

Maybe I missed something..but it sounds to me like what Dave did was just add an option in the /etc/fstab, that was or may not have been set on the file system when it was created.

Dave,
Since the f/s are down, have you tried:

fsadm -F vxfs -o largefiles /dir/path/fs

So now they have that option & then try to run the mount -a and see if they mount now.

Rgrds,
Rita

[The Gunners]

Hi Everyone , Thanks so much for the posts so far - Rita you have it exactly , I changed the entry for the oracle filesystems to 'largefiles' from 'nolargefiles' by editing the /etc/fstab (as far as I remember) sometime back (only in the last year or so if even as this server was only built then.

The command you have suggested - ie fsadm -F vxfs -o largefiles (this wont wipe data will it as I have to keep the database files that are on these filesystems)
So for example lets pick the first one that wont mount - would the command be
fsadm -F vxfs -o largefiles /dev/vg01/lvol3/oracledata1 ?


Thanks again,
Dave

[Matti_Kurkela]

Almost correct - this is the command you need:

fsadm -F vxfs -o largefiles /dev/vg01/lvol3

The filesystem on disk /dev/vg01/lvol3 does not include the "oracledata1" name. Neither is it tied to that name in any way. The root directory of the /dev/vg01/lvol3 filesystem is associated with /oracledata1 only because you're mounting it there - you could just as well mount it to some other location if necessary.

For example, if your vg01 hits the LVM size limits someday in the future, you might have to do something like this:
(Assume you have already created another VG, named vgBIG for this.)

(shutdown Oracle)
mkdir /oracledata1.old
umount /oracledata1
mount /dev/vg01/lvol3 /oracledata1.old
mount /dev/vgBIG/lvol1 /oracledata1
cp -rp /oracledata1.old/* /oracledata1/
(restart Oracle)

With this, you'll migrate your files from /dev/vg01/lvol3 to /dev/vgBIG/lvol1... and since the new filesystem is mounted exactly where the old one was, there is no need to change any configured paths within Oracle.

MK

[The Gunners]

Hi again , Ismail thanks for your update last nite - this is very strange , I issued your mount command and the mount commands for all the other three missing filesystems and they worked - see below

mount /dev/vg01/lvol3 /oracledata1
mount /dev/vg02/lvol1 /oracledata2
mount /dev/vg01/lvol4 /oracledata3
mount /dev/vg02/lvol4 /oracledata4
dubhptst:etc # bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 278528 167048 110664 60% /
/dev/vg00/lvol1 298928 44208 224824 16% /stand
/dev/vg00/lvol8 4718592 772232 3918704 16% /var
/dev/vg00/lvol7 2637824 1324440 1303160 50% /usr
/dev/vg01/lvol5 819200 16668 752379 2% /ua
/dev/vg01/lvol11 212992 1893 197945 1% /tsl
/dev/vg00/lvol4 3686400 34624 3623408 1% /tmp
/dev/vg02/lvol6 819200 116186 659130 15% /sqr
/dev/vg02/lvol9 7176192 5246437 1809153 74% /scratch2
/dev/vg01/lvol10 20480000 9513775 10281079 48% /scratch
/dev/vg02/lvol10 360448 1190 336810 0% /sapips
/dev/vg01/lvol2 25608192 6309027 18093001 26% /oracle10
/dev/vg00/lvol6 4505600 3018920 1475080 67% /opt
/dev/vg01/lvol7 4096000 423461 3449547 11% /ips
/dev/vg00/lvol5 32768 2280 30264 7% /home
/dev/vg02/lvol15 30720000 23994 28777513 0% /export
/dev/vg01/lvol3 30720000 9201139 20173935 31% /oracledata1
/dev/vg02/lvol1 25608192 5439838 18907836 22% /oracledata2
/dev/vg01/lvol4 2048000 177466 1753631 9% /oracledata3
/dev/vg02/lvol4 2048000 177466 1753631 9% /oracledata4
dubhptst:etc #

I guess my next question is why they didnt mount after the reboot ?

[rariasn]

Hi Dave:

Verify your /etc/lvmrc configuration file.

rgs,

[The Gunners]

Hi Rariasn, thanks for reply, looks fine to me or what should I be looking for in this file ?

dubhptst:etc # ls -al lvmrc
-rw-rw-r-- 1 bin bin 1424 Nov 15 2000 lvmrc
dubhptst:etc # cat lvmrc
# @(#)B.11.11_LR
# /etc/lvmrc
#
# This file is sourced by /sbin/lvmrc. This file contains the flags
# AUTO_VG_ACTIVATE and RESYNC which are required by the script in /sbin/lvmrc.
# These flags must be set to valid values (see below).
#

#
# The activation of Volume Groups may be customized by setting the
# AUTO_VG_ACTIVATE flag to 0 and customizing the function
# custom_vg_activation()
#

#
# To disable automatic volume group activation,
# set AUTO_VG_ACTIVATE to 0.
#

AUTO_VG_ACTIVATE=1

#
# The variable RESYNC controls the order in which
# Volume Groups are resyncronized. Allowed values
# are:
# "PARALLEL" - resync all VGs at once.
# "SERIAL" - resync VGs one at a time.
#
# SERIAL will take longer but will have less of an
# impact on overall I/O performance.
#

RESYNC="SERIAL"


#
# Add customized volume group activation here.
# A function is available that will synchronize all
# volume groups in a list in parallel. It is
# called parallel_vg_sync.
#
# This routine is only executed if AUTO_VG_ACTIVATE
# equals 0.
#

custom_vg_activation()
{
# e.g. /sbin/vgchange -a y -s
# parallel_vg_sync "/dev/vg00 /dev/vg01"
# parallel_vg_sync "/dev/vg02 /dev/vg03"

return 0
}

#
# The following functions should require no additional customization:
#

parallel_vg_sync()
{
for VG in $*
do
{
if /sbin/vgsync $VG > /dev/null
then
echo "Resynchronized volume group $VG"
fi
} &
done
}

[rariasn]

Hi:

JRF: The 'largefiles' or 'nolargefiles' option as placed in '/etc/fstab' _only_ tells you the intention at mount-time. That is, if 'nolargefiles' is set there, and you try to mount a fileystem with a 'largefiles' bit set, the mount fails.

http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1289909933828+28353475&threadId=1338286


Test mount options:

- stop oracle application.

# umount /oracledata1
# umount /oracledata2
# umount /oracledata3
# umount /oracledata4

P
# fsadm -v -F vxfs dev/vg01/rlvol3

...

--> largefiles

# mount /oracledata1
# mount /oracledata2
# mount /oracledata3
# mount /oracledata4

rgs

[James R. Ferguson · Accepted solution]

Hi (again) Dave:

> Rita you have it exactly , I changed the entry for the oracle filesystems to 'largefiles' from 'nolargefiles' by editing the /etc/fstab (as far as I remember) sometime back (only in the last year or so if even as this server was only built then.

Dave, slow down and re-read the whitepaper I suggested. It says (in part), "the mount command will not mount a no-large-files filesystem if the -o largefiles option is specified."

Given the change you made it is expected that a subsequent mount() would fail.

> The command you have suggested - ie fsadm -F vxfs -o largefiles (this wont wipe data)

No this won't. This only changes a bit in the filesystem metadata. The command will only take a fraction of a second to run, too.

Regards!

...JRF...

[The Gunners]

Hi James,
Thanks a mill. I have run the fsadm -F vxfs -o largefiles command on all four filesystems. I then mounted them and all were ok.
I have just done a reboot , and all filesystems came up themselves so this is sorted.
Points on the way to everyone. Thanks a mill. This is such an invaluable resource and a great learning tool for us Oracle DBA's who have little unix knowlegde in these type of issues.
Many thanks again folks.