root filesystem filling up - directory sizing

[Adam Noble]

Hi all,

I have an NFS mount /work/payments. It is clearly shown as an NFS mount when I do a bdf. The issue is when I cd into /work and do an ll. I see that the directory has a size of 1540096 which I believe is actually taking space from the root filesystem. I assume this is due to the number of files in the directory which is 59737

I've not seen this before is there anyway of resolving this without extending root.

Cheers

[Mridul Shrivastava]

What are these files...

You can try house keeping of these files by moving them to other directory or take tape backup..

[Adam Noble]

Sorry I'm not making myself clear my fault. No I appreciate I can remove files within the directory but the directory itself seems to have a size of 1540096 which is actually taking space from / when infact the files actually reside within that directory on an NFS mount.

[Hasan Atasoy]

hi adam ;

you need to rmdir and recreate the directory itself.

move files to another locatin.
rmdir that directory
mkdir that director.
move files back to org location.


Hasan.

[Mridul Shrivastava]

it is NFS Client or Server ??

If it is client then unmounting the NFS and then recreating the mount point may resolve the issue.

[Dennis Handly]

>The issue is when I cd into /work and do an ll. I see that the directory has a size of 1540096 which I believe is actually taking space from the root filesystem.

No, you are looking at the mounted directory. To see the under mount point directory size, you have to unmount the NFS directory. Or go to another machine and look at /work.

>is there anyway of resolving this without extending root.

This is not related to root. Obviously root can't have entries made for files on NFS, only the mount point.

>but the directory itself seems to have a size of 1540096 which is actually taking space from /

No, when you ask for info of the NFS directory, you get the info from the server, not root. An ll in /work/, will actually read the NFS payments/ directory to get its size and permissions, perhaps leading to your confusion.

>Hasan: move files to another location.
... move files back to org location.

You are wasting steps here. You should mkdir, then mv *, then rmdir, then mv new directory to old.

[Adam Noble]

Ok lets start again. I am well aware that the directory itself contains files which are not taking space from the root filesystem. I've just never seen before a situation that when you do a listing on a directory I am talking ll that u get a value such as this one which is 1540096. If I do a du -sk for example on the directory it is 3215502 which clearly does not tally. Also if I do a find / -xdev +100000c it picks up /work/payments. I would not expect this. Its without doubt showing up as a directory when I do a listing. Just unsure what determines the directory size value. If for example you do an ll -d /opt or ll -d /tmp they both show 8192 and clearly do not relate to amount of files or sizes of them within the directory!!!

[Hasan Atasoy]

hi adam ;

if you copy lots of files to a directory, directory size itself will increase. it will not decrease even though you remove all files in it. so you need to create that directory with removing first in order to make it in small size.

Hasan.

[john korterman]

Hi Adam,

the size of a directory file does not shrink automatically; when you create a new file in a directory, hpux adds an entry to the directory file about the inode and the name of the file. If you then delete the file, the entry in the directory file is not deleted, but rather registered as "free" - "free" entries will be used when new files are added, but till then they are just there for no reason.

A huge directory file thus shows that at a certain time the directory held many files; however, it may no longer be the case.

regards,
John K.

[Dennis Handly · Accepted solution]

>I am well aware that the directory itself contains files which are not taking space from the root filesystem.

And neither is the directory, except for the "empty" mount point.

>Also if I do a find / -xdev +100000c it picks up /work/payments. I would not expect this.

I wouldn't either. I would expect the command is broken and possibly off by one for directories. But if you want to check, unmount that file system and then look.

>Just unsure what determines the directory size value. If for example you do an ll -d /opt or ll -d /tmp they both show 8192 and clearly do not relate to amount of files

They are "related" to the number of files. Directories are allocated in blocks that contain the names and pointers to the files. And they contain holes if you ever created lots of files then removed them.

To get an idea of the directory format you can look at these man pages:
getdirentries(2) directory(3C) dir(4) dirent(5)
Some are to be obsoleted and some are for HFS.

Note: Some commands aren't smart enough to disallow reading a directory as a data file. I think grep is one.

[Adam Noble]

Ok thanks for all of your assistance

[Dennis Handly]

>ME: I would expect the command is broken and possibly off by one for directories.

Oops, it isn't broken, it is clearly documented in find(1):
-xdev ... The mount point itself is visited, but entries below the mount point are not.

So this would always pick up mount point directories.