Where did the space go?

[Bill Hassell]

Not sure exactly where the 70 mb went to but since you have 32 unassigned extents, you could just extend the new lvol by 18 extents, then run extendfs to make the filesystem bigger and you'll have 72 additional megs. Or assign all 32 unused extents (+ run extendfs) and you'll have 128 megs additional space.

[linuxfan]

hi Todd,

Quick glance tells me you are creating a LV with a size of 8500 MB but are creating a fs of only 8192MB (so you can still extend your filesystem by 308 MB)leaving your existing 31 extents (128MB) free.

-Ramesh

[Todd Bowden]

I know there is LE's that I can use but I want to get an explanation of why with the same amount of allocated LE's can I not get the same amount of information in the filesystem. I was talking with HP and they referred to LVM overhead.

[Animesh Chakraborty]

Hi,
I think only root id can use exactly 100 % of a file system.For other user it will give warning as file system full when it reaches 90%.Please correct me if I am wrong.


Thanks
Animesh

[Volker Borowski]

Hey Todd,

by saying RESTORE, do you refer to "brrestore", the tool to restore a SAP database ?

brrestore refuses to restore, if filesystem usage will be greater than 98% after restore!

Hopefully, you have only a few filesystems violating this rule. In this case, check, if you can relocate some files.

I.E, if only one datafile causes error, you could try to split the restore.

Say PSAPTEMP has 6GB and temp.data1, temp.data2, temp.data3 have 2G each.
temp.data2, temp.data3 reside on a 4GB filesystem with 100% utilisation (i.e. sapdata3). The rest is on filesystems with 98% or less.
You would go with several runs then :
brrestore -m SYSTEM,PSAPBTABD,PSAPBTABI,...
put all Tablespaces but PSAPTEMP in it.

Second run (splitting lines for better visibility)

brrestore
-m /oracle/SID/sapdataX/temp_1/temp.data1,
/oracle/SID/sapdata3/temp_2/temp.data2,
/oracle/SID/sapdata3/temp_3/temp.data3=/oracle/SID/sapreorg

Now the key is the relocation to sapreorg (or whereever the space is). Restore will succeed, and you can mv the file back to sapdata3, where it belonged. Check the SAP-manual for brrestore in addition.

I know this is odd, but in SAP environment, you should not utilize sapdata filesystems with more than 98%. When your restore is good, consider to relocate a file, to avoid this.
I do not know if SAP is working on a patch for this, but it might be worth, checking sapservX for the latest brrestore.

Hope this helps
Volker

[Todd Bowden]

Thanks to all so far who have replied. I did a test on my production box and again when I created this LV with 8500MB it still shows that I only have:

/dev/testvg/saptest
8704000 2544 8633488 0% /saptest

My question is where is the rest of the space, if you subtract 8633488 from 8704000 you get 70512, and according to the used space which is 2544KB I should have more space than 8633488, right? I have the space on another filesystem that has the same LE assigned, but it is utilizing all of the space. How can I get the same result on the other filesystem?

Todd

[John Palmer · Accepted solution]

Hi Todd,

You have defaulted the number of i-nodes when creating /dev/sapvg13/rsapdata9, resulting in an overhead of about 70Mb.

I suspect that whoever created the original production filesystem only specified a very small number of i-nodes as the overhead only appears to be about 40Kb.

Try comparing the number of i-nodes in each filesystem...

bdf -i ...

You should see a very small number for the production filesystem, 40Kb should be 160 i-nodes.

Try recreating your filesystem as follows:-
newfs -F vxfs -o largefiles
-o ninode=160 /dev/sapvg13/rsapdata9

Regards,
John

[Todd Bowden]

The result of specifying the ninode worked. My question is how did the other fileystem get created and works? A mkfs -m output of each filesystem is like so:


/ # mkfs -F vxfs -m /dev/sapvg13/sapdata9
mkfs -F vxfs -o ninode=unlimited,bsize=8192,version=3,inosize=256,logsize=256,largefiles /dev/sapvg13/sapdata9 8704000


/ # mkfs -F vxfs -m /dev/testvg/saptest
mkfs -F vxfs -o ninode=160,bsize=8192,version=3,inosize=256,logsize=256,largefiles /dev/testvg/saptest 8704000

See the ninode in the first one is unlimited just like I had this saptest filesystem before I changed it. Im seeing now the filesystem space I want but obviously these filesystems where created the same.

Any ideas on why I had to specify the ninode parameter to be equal to 160 in order for me to see the space I needed to see. I would love to hear anyones thoughts on this.