Filesystems wont mount even though they are in fstab

[The Gunners]

Hi I have a strange problem . Cant figure it out so thought I'd bounce it off you great people.
Basically , I rebooted a unix Server (HP/UX) When it came back up I was missing about 5 filesystems (where Oracle resides as it happens) - no hardware issues etc that I can see. When i try to mount one of these individually I get (for example)
dubhptst: # mount /oracledata1
vxfs mount: mount option(s) incompatible with file system /dev/vg01/lvol3

Here are the entries in my fstab
Anyone any ideas - they have been up and running for a long time and didnt have problems before

/dev/vg01/lvol3 /oracledata1 vxfs rw,suid,largefiles,delaylog,datainlog 0 2
/dev/vg02/lvol1 /oracledata2 vxfs rw,suid,largefiles,delaylog,datainlog 0 2
/dev/vg01/lvol4 /oracledata3 vxfs rw,suid,largefiles,delaylog,datainlog 0 2
/dev/vg02/lvol4 /oracledata4 vxfs rw,suid,largefiles,delaylog,datainlog 0 2


Thanks a mill,
Dave

[The Gunners]

Hi , just an update to above , I think the 'largefiles' is the prob. I just edited the fstab at the time rather than originally creating them for 'largefiles'
I need to keep the data obviously that is on them , how do I get around this one ?
Thanks,
D

[TTr]

You can set the largefiles option for the volumes and then they should mount.

man fsadm_vxfs

[James R. Ferguson]

Hi Dave:

> I think the 'largefiles' is the prob.

No, the specification simply says that if the underlying filesystem has any largefiles then it's OK to mount. If you had said 'nolargefiles' and yet the filesystem contained some, then the mount would fail.

The problem is likely the 'detainlog' option. This is only available with OnLineJFS. Do you have that?

Regards!

...JRF...

[Ismail Azad]

Hi Davey,

Something doesn't sound right. Can you post the exact output. Because mount /oracledata1 would do nothing but give you an error. Let's start with something simple try mount /dev/vg01/lvol3 /oracledata1 and then give the error. Besides, the error gives /dev/vg01/lvol3 is a filesystem?? Anyways try it out and what's ur operation system version?

Regards

[Ismail Azad]

Hi,

As JRF said execute the following command swlist -l product | grep -i Online and check if your using the base JFS or online JFS. Easiest way to know this is if your working on filesystems you would be doing an extendfs on Base JFS and an fsadm on Online.

If it's installed, prob the following commands would help for your problem :-

/sbin/bcheckrc stop
/sbin/bcheckrc start

Hope the info helps

Regards

[Steven E. Protter]

Shalom,

largefiles is an invalid parameter for /etc/fstab since 11iv1 and mount attempts with it set will fail.

After taking this out, try mount -a and post the results.

SEP

[James R. Ferguson]

Hi (again) Dave:

> Anyone any ideas - they have been up and running for a long time and didnt have problems before

Define "long". There was a case of OnlineJFS licenses expiring over three years ago. See :

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1439325

...including the URL I offered therein.

Regards!

...JRF...

[James R. Ferguson]

Hi (again):

> SEP: largefiles is an invalid parameter for /etc/fstab since 11iv1 and mount attempts with it set will fail.

This is *NOT* true. Re-read my post in this thread, the manpages or for that matter the 10.0 Largefiles whitepaper which states:

"mount will not mount a large-files filesystem if the -o nolargefiles option is specified. Conversely, the mount command will not mount a no-large-files filesystem if the -o largefiles option is specified. If no option is provided to mount, it will use the state of the filesystem itself to determine if it is mounted as largefiles or nolargefiles."

See:

http://docs.hp.com/lgfiles4.pdf

Regards!

...JRF...

[Ismail Azad]

>SEP

The largefiles and nolargefiles are still valid. Just tried the option on a 11iv3 operating system. It's still very much a mount option. Although HFS filesystems are deprecated, they are still supported even on 11iv3 for backward compatibility. The default mount option on hfs is "nolargefiles", if this option is not present what would be the default mount options on an HFS filesystem just in case (hypothetically) someone mounted a filesystem as HFS . The option is still there and LARGEFILES is still considered to be a default option. :) steven

Regards

[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.