topic Re: vx_nospace, but bdf says there is enough space in Operating System - HP-UX

vx_nospace, but bdf says there is enough space

Francisco Mancardi_1 — Fri, 04 Jan 2002 20:50:19 GMT

This is a bdf of my system (HP-UX 10.20)

Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 143360 71622 67560 51% /
/dev/vg00/lvol1 83733 20620 54739 27% /stand
/dev/vg00/lvol9 3072000 2616118 434612 86% /var
/dev/vg00/lvol8 700416 534147 155898 77% /usr
/dev/vg00/lvol7 102400 12183 84986 13% /tmp
/dev/vg00/lvol6 3072000 2146835 867350 71% /opt
/dev/vg00/lvol5 53248 41360 11395 78% /home

But while editing a file using vi , I've got the following message
vxfs: mesg 001: vx_nospace - /dev/vg00/lvol9 file system full (8 block extent)

I'm very confused, because there is a 14% free on /var (according to bdf)

Any hint ?

Thanks

Francisco

Re: vx_nospace, but bdf says there is enough space

Helen French — Fri, 04 Jan 2002 20:55:07 GMT

Hi,

Check this out:

http://us-support.external.hp.com/cki/bin/doc.pl/sid=907d1c751af3ae7df3/screen=ckiDisplayDocument?docId=200000041499374

HTH,
Shiju

Re: vx_nospace, but bdf says there is enough space

Darrell Allen — Fri, 04 Jan 2002 20:56:06 GMT

Hi Francisco,

vi is using /var/tmp for a copy of the file while you are editing it. Are you editing a file that is larger than ~430MB? If so, you are really filling /var.

Darrell

Re: vx_nospace, but bdf says there is enough space

harry d brown jr — Fri, 04 Jan 2002 21:02:12 GMT

Fortunately it was a warning and not an error! What other processes are using /var? Do you have "lsof" on your system?

live free or die
harry

Re: vx_nospace, but bdf says there is enough space

Helen French — Fri, 04 Jan 2002 21:03:37 GMT

Hi,

This may help you:

http://us-support.external.hp.com/cki/bin/doc.pl/sid=d3a107a41b62a0466f/screen=ckiDisplayDocument?docId=200000050087829

Shiju

Re: vx_nospace, but bdf says there is enough space

Uday_S_Ankolekar — Fri, 04 Jan 2002 21:04:40 GMT

Hi,

vi looks for buffer space in /var/tmp

Check if any bigfiles which is causing this problem This will check files more than 10MB , if the file is not required then delete and then try vi.

find /var -type f -xdev -size +10000000c -exec ll {} \;

-Goodluck,
-USA..

Re: vx_nospace, but bdf says there is enough space

Francisco Mancardi_1 — Tue, 08 Jan 2002 14:30:28 GMT

Hi!
I've read the documentation, but stil I'm needing help.

I would like to defragment /var, but the info I've got from
fsadm is not enough.

Could anyone give some hint or (a must) the procedure
to do the defrag ?

Thanks a lot

Francisco

Re: vx_nospace, but bdf says there is enough space

James R. Ferguson — Tue, 08 Jan 2002 15:25:54 GMT

Hi:

I don't think defragmenting /var is going to help you as much as potentially cleaning up unnecessary files. I'd start by running the 'cleanup' utility to manage files in /var/adm/sw/ [the *only* way this directory should ever be managed!].

If you are running 11.x:

# cleanup -c 1

If you are running 10.20:

# cleanup

Regards!

...JRF...

Re: vx_nospace, but bdf says there is enough space

Bill Hassell — Tue, 08 Jan 2002 16:57:56 GMT

I would not look for big files in /var at all. Look instead for big directories. You may have 25,000 files in /var/tmp that are 900kb each and find will miss them all. Here's the way to locate the big directories:

# du -kx /var | sort -rn > /tmp/du.var

Now look at the /tmp/du.var file to see what is at the top of the list.

From this information, you may see that only one or two directories occupy most of the space. Now it's time to improve the reliability of the system by separating portions of /var to prevent interaction.

For instance, depending on what is running on the box, the following directories should be moved to separate logical volumes:

/var/tmp
/var/spool
/var/mail
/var/adm
/var/adm/crash
/var/adm/sw

There may be others, but these are the most common. Note that bdf uses a different mechanism to calculate disk space when compared to ls and du. bdf shows inconsistent results for vxfs mount points versus the corresponding device file. For the HFS filesystem, inodes and superblocks are preset via newfs but for the Journaled File System
there are no fixed inode allocations. Instead, VxFS filesystems consist of a number of dynamic attributes that describe the filesystem. These dynamic attributes are called structural files and they are kept in a separate fileset (Fileset 1) from the user files (Fileset 999).

Since these structures are dynamic and can grow as more files are added to the filesystem, it is impossible to determine how much space will be used used by structural files and how much space will be used by user files. Unlike an HFS filesystem, where all the inodes are preallocated when the filesystem is created, a VxFS filesystem can continue to allocate more inodes as needed. However, each time a new block of inodes is allocated, the number of actual data blocks are reduced.

So bdf and du must guess as to the number of inodes that might be needed and the space available. The bdf 'used' column represents space used by both user files and structural files. The bdf 'avail' column represents the Kbytes available after subtracting the actual Kbytes used and the estimated Kbytes needed for inodes.

Re: vx_nospace, but bdf says there is enough space

Francisco Mancardi_1 — Wed, 16 Jan 2002 16:26:44 GMT

Hi, I'm still trying to solve the problem.

info about i-nodes:

# bdf -i
Filesystem kbytes used avail %used iused ifree %iuse Mounted on
/dev/vg00/lvol3 143360 88329 51874 63% 5560 13756 29% /
/dev/vg00/lvol1 83733 20620 54739 27% 18 13422 0% /stand
/dev/vg00/lvol9 3072000 2641855 410835 87% 24233 107535 18% /var
/dev/vg00/lvol8 700416 537735 152521 78% 17379 40669 30% /usr
/dev/vg00/lvol7 102400 6081 90709 6% 186 24078 1% /tmp
/dev/vg00/lvol6 3072000 2242071 778147 74% 49310 207482 19% /opt
/dev/vg00/lvol5 53248 20683 31063 40% 1230 8138 13% /home

seems there is no problems with /var

fsadm -F vxfs -E /var

# fsadm -F vxfs -E /var
Extent Fragmentation Report
Total Average Average Total
Files File Blks # Extents Free Blks
18161 144 60 430150
blocks used for indirects: 19223
% Free blocks in extents smaller than 64 blks: 100.00
% Free blocks in extents smaller than 8 blks: 100.00
% blks allocated to extents 64 blks or larger: 30.76
Free Extents By Size
1: 430130 2: 2 4: 4 8: 0
16: 0 32: 0 64: 0 128: 0
256: 0 512: 0 1024: 0 2048: 0
4096: 0 8192: 0 16384: 0 32768: 0

It seems to me that there is no fragmentation (may be
I'm not understanding the meaning of this figures ?).

But my problem with vi persists.

I'm usign this platform to run NNM, and it stores it's
databases in /var.
I have a good number of files in the directory where NNM
stores what is called DataCollections.
(1885 files).

waiting for help ...