Help resizing filesystem

[Tim Lines]

Oracle dba asked me to increase the size of /oracle. So I:

(0)dbtest5:/ 3# lvextend -L 40000 /dev/dbtest5datavg/oracle

Logical volume "/dev/dbtest5datavg/oracle" has been successfully extended.
Volume Group configuration for /dev/dbtest5datavg has been saved in /etc/lvmconf/dbtest5datavg.conf

(0)dbtest5:/ 4# fsadm -b 40000m /oracle
fsadm: /etc/default/fs is used for determining the file system type
vxfs fsadm: /dev/dbtest5datavg/roracle is currently 20480000 sectors - size will be increased
vxfs fsadm: attempt to resize /dev/dbtest5datavg/roracle failed with errno 28
vxfs fsadm: Retry the operation after freeing up some space

Am I really out of space?

(32)dbtest5:/ 5# bdf /oracle
Filesystem kbytes used avail %used Mounted on
/dev/dbtest5datavg/oracle
20480000 15303259 4854140 76% /oracle

Doesn't look lines it. Why does fsadm think I'm out of disk space?

[Steven E. Protter]

Shalom,

Very interesting results.

If could be that there is a file handle open on a file that has been deleted in the /oracle filesystem.

Or fsadm doesn't like the m parameter. I used to use it without parameters. Perhaps its interpreting your request as a reduction of the filesystem. Thats my idea.

SEP

[A. Clay Stephenson]

This:
fsadm -b 40000m /oracle

40000 * 1024 = 40960000
should be:

fsadm -F vxfs -b 40960000 /oracle

[Tim Lines]

>Or fsadm doesn't like the m parameter. I >used to use it without parameters. Perhaps >its interpreting your request as a >reduction of the filesystem. Thats my idea.

OK. The part where fsadm says "size will be increased" argues against that.

Also, when I follow Clays advice, I get:

(0)dbtest5:/ 15# fsadm -F vxfs -b 40960000 /oracle
vxfs fsadm: /dev/dbtest5datavg/roracle is currently 20480000 sectors - size will be increased
vxfs fsadm: attempt to resize /dev/dbtest5datavg/roracle failed with errno 28
vxfs fsadm: Retry the operation after freeing up some space

(32)dbtest5:/ 16# bdf /oracle
Filesystem kbytes used avail %used Mounted on
/dev/dbtest5datavg/oracle
20480000 18552129 1807679 91% /oracle

So it's apparently something besides the "m".

[A. Clay Stephenson]

Ok, let's ask the box how big it thinks the LVOL is.

lvdisplay /dev/dbtest5datavg/oracle

and post the output.

Also, is there a lost+found directory in this file system?

[Tim Lines]

(0)dbtest5:/ 1# lvdisplay /dev/dbtest5datavg/oracle
--- Logical volumes ---
LV Name /dev/dbtest5datavg/oracle
VG Name /dev/dbtest5datavg
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 40000
Current LE 5000
Allocated PE 5000
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation strict
IO Timeout (Seconds) default

(0)dbtest5:/ 2#

[A. Clay Stephenson]

Ok, your fsadm command should work. You do have a lost+found directory so that fsadm can create a .fsadm file don't you? The only other whackball idea is that largefiles are not enabled. I suppose that the next step is to shutdown the database and try to growth the filesystem. If that fails, unmount it and try.

[chris huys_4]

Hi Tim,

I think you should do what the error says. Free up some filesystemspace. To increase a filesystem the filesystem needs also some free space. Youre increase from 20gig to 40gig probably needs more free space that currently is available.

If you cant free up more filesystemspace, I would umount the filesystem and do the extending with extendfs.

Greetz,
Chris

[SGUX]

maybe a silly idea but is it worth trying extending the filesystem in portions, like
first :
fsadm -F vxfs -b 30720000 /oracle
and when this works;
fsadm -F vxfs -b 40960000 /oracle

[Tim Lines]

Clay,
Yes, there is a lost+found directory:
drwxr-xr-x 2 root root 96 Sep 8 2004 lost+found

Chris,
I freed up another 5 GB on /oracle. fsadm continues to fail in the same way.

Francois,
Attempting the filesystem expansion piecemeal changed nothing; it fails with 30720000 in the same way as 40960000

Thanks for the suggestions.

[Tim Lines]

Enabled largefiles via fsadm. Didn't help.

[A. Clay Stephenson]

I keep thinking that we are somehow overlooking the obvious here. I do note that when your first reported the file system was at 76% and then a little later at 91% which is a rather fast growth for a 20GiB file system.

Do this and post the results:
fstyp -v /dev/dbtest5datavg/oracle
df -i /dev/dbtest5datavg/oracle
bdf /dev/dbtest5datavg/oracle

Do those commands quickly in succession so that the different looks at the same data should reasonably agree.

One other possible thing to examine is a grossly over committed file system because of sparse files. I'm not sure of the behavior of fsadm -b in that case. You might total up the lengths of all the files using a find . -type
f -exec ls -l {} \+ and compare that to
the bdf totals. If the totals of the file lengths significantly exceed the bdf output then you have a lot of sparse files.

[Tim Lines]

> I keep thinking that we are somehow
> overlooking the obvious here.

Yeah, me too.

> I do note that when your first reported
> the file system was at 76% and then a
>little later at 91% which is a rather fast
> growth for a 20GiB file system

Well, it is. /oracle with a couple 9i instances fills up ~76% of the fs, while /oracle with a couple 9i instances plus 10.1 is ~ 91%. It's because we're adding 10.1 and 10.2 that we're expanding /oracle.

I've moved the 10.X instances to a different filesystem while we troubleshoot this, so it' ~74%. With the exception of install logs etc., this fs is pretty static.

[Tim Lines]

We shut oracle down and restarted it. Now the fsadm command to resize the filesystem has completed successfully.

Thanks, all. I really appreciate your help and patience.

[Tim Lines]

As mentioned in my earlier thread, shutting down oracle and restarting it allowed the file system resize to work. Steven Prosser (?) had speculated earlier that a file in /oracle had been deleted that a process still had open. Seems like a good possibility.