vx_nospace, but bdf says there is enough space

[Francisco Mancardi_1]

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

[Helen French · Accepted solution]

Hi,

Check this out:

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

HTH,
Shiju

[Darrell Allen]

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

[harry d brown jr]

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

[Helen French]

Hi,

This may help you:

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

Shiju

[Uday_S_Ankolekar]

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

[Francisco Mancardi_1]

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

[James R. Ferguson]

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

[Bill Hassell]

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.

[Francisco Mancardi_1]

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