Finding files hidden under mountpoints

[Dermot Beirne]

Hi,
I have a problem with space on one of my filesystems. After investigation I find that, it still has over 500 mb of used space and not from my files. I cannot unmount this to see if there are files "under" it. I also realise that the inode table, superblocks and newfs command all reserve space on a file system.
Looking at the ncheck and ff commands seems to indicate that you need to know what to grep for if you want to check for files hidden under the mountpoint.
Example from a different server:
bdf returns:
/dev/vg03/lvol2 9371648 41005 8784981 0% /u2

dfspace returns:
/u2 : Disk space 8579.08 MB of 9152.00 MB available (93.74%)

This is a HP9000 D Class running HPUX 11.0
This filesystem only have one empty directory, the default Lost+found.
How can I find out what space the system has reserved, and make sure that there isn't something else "stealing" my space, i.e. files hidden under this mount-point. How can use the ncheck command to locate hidden files, when I don't know what to grep for.

Any help would be appreciated.
Thanks & regards
Dermot.

[Pedro Sousa]

Dermot,
to check your inode table, you should do 'bdf -i'.

I've never heard about files under mount-point filling it up! I don't think it's possible. The only thing it can fill is the parent filesystem.

Check witch processes are running on that lvol:
fuser /dev/vg/lvol

kill them if necessary (be carefull).

Check the size again, try to umount it.
good luck.

[Vincenzo Restuccia]

du -k /u2/*|more
find /u2 -size +xxx

[Pedro Sousa]

You can always use 'du -sk *' inside the fs to check the size of every folder (I know you just have lost+found).

[Dermot Beirne]

Hi,
If i create a directory and put a file in it, then if i mount, say, the /cdrom onto this directory, I can no longer see the file I created until I unmount the /cdrom again. It is however, using up space.
I suspect that there may be file created in /u2 before it was used as a mount point, and therefore, they are there, invisible, but still using space. I don't think du shows these? Isn't that what ncheck is for?
thanks for you replies.
Dermot

[Volker Borowski]

Hello,

I never tried to verify this on HP-UX, but I was once trapped on a Solaris box with this:

nfsserver:
local disk fs /home/exp
local disk fs /home/exp/subfs1

nfsclient
nfs fs nfsserver:/home/exp on local dir /mount

On nfsclient, you see dir
/mount/subfs1
but ! it is empty !

If you put a file there on the nfsclient you can see and access it on nfsclient.
On nfsserver you see the file, when you unmount
/home/exp/subfs1 !

I do not remember exactly, but I think it was either a bug or a solaris specific mount-option.

Do not know if this helps.

I would try a
find . -print > listfile

on client and server, and compare the lists.

Volker

[Pedro Sousa]

I still think that you should use that "fuser".

but, if you want to use ncheck:
ncheck -F /dev/vg/lvol

This will give you all the files and the associated inode table. If you say you don't have any files on that mount point, maybe, and just may be, it shows the "under" files.
good luck.

[Carsten Krege]

Pedro is right:
1) files under the mountpoint fill up the parent filesystem only
2) it is good to check for processes that keep files open that were already deleted. bdf will report the disk space used by these files as "used" , whereas du does report the space as free. Stopping processes that keep open deleted files, let bdf report the disk space as "available" again.
3) It appears that you use VxFS. For HFS you would have 10% minfree missing. If you create a VxFS filesystem you get an idea how the space is used for admin information, by the output of newfs, e.g.

# lvcreate -l 160 /dev/vgcifs
Logical volume "/dev/vgcifs/lvol3" has been successfully created with
character device "/dev/vgcifs/rlvol3".
Logical volume "/dev/vgcifs/lvol3" has been successfully extended.
Volume Group configuration for /dev/vgcifs has been saved in /etc/lvmconf/vgcifs.conf
# newfs -F vxfs /dev/vgcifs/rlvol3
version 3 layout
655360 sectors, 655360 blocks of size 1024, log size 1024 blocks
unlimited inodes, 655360 data blocks, 654112 free data blocks
20 allocation units of 32768 blocks, 32768 data blocks
first allocation unit starts at block 0
overhead per allocation unit is 0 blocks
# bdf /dev/vgcifs/lvol3
Filesystem kbytes used avail %used Mounted on
/dev/vgcifs/lvol3 655360 1261 613218 0%

You see that there is a logsize of 1024 blocks reserved (=1MB).

For a VxFS version 2 filesystem you have even more overhead:

# mkfs -F vxfs -o version=2 /dev/vgcifs/rlvol3
version 2 layout
655360 sectors, 655360 blocks of size 1024, log size 1024 blocks
unlimited inodes, 653632 data blocks, 653519 free data blocks
10 allocation units of 65600 blocks, 65536 data blocks
last allocation unit has 63808 data blocks
first allocation unit starts at block 1088
overhead per allocation unit is 64 blocks
initial allocation overhead is 113 blocks

# bdf /dev/vgcifs/lvol3
Filesystem kbytes used avail %used Mounted on
/dev/vgcifs/lvol3 655360 1841 612668 0%


To prove that most of the usage is the filesystem log, I will give you another mkfs for a VxFS version 3 with reduced logsize (this compares directly with the first newfs output):

# mkfs -F vxfs -o logsize=32 /dev/vgcifs/rlvol3
version 3 layout
655360 sectors, 655360 blocks of size 1024, log size 32 blocks
unlimited inodes, 655360 data blocks, 655104 free data blocks
20 allocation units of 32768 blocks, 32768 data blocks
first allocation unit starts at block 0
overhead per allocation unit is 0 blocks
# bdf /dev/vgcifs/lvol3
Filesystem kbytes used avail %used Mounted on
/dev/vgcifs/lvol3 655360 269 614148 0%

You see that bdf shows the size of the log as "used" space. However, I wouldn't recommend to reduce the logsize of the filesystem although this is most likely the diskspace eater you are searching.

For a VxFS version 2 filesystem you can check the logsize of the filesytem by

# echo "8 b; p S" | fsdb -F vxfs /dev/vgcifs/lvol3
super-block at 00000008.0000
magic a501fcf5 version 2 ctime Mon May 7 12:10:53 2001
log_version 6 logstart 17 logend 1040

=> logend-logstart=logsize.

This doesn't work for version 3 VxFS though. For a VxFS version 3 the logsize is 256k at minimum.


Carsten

[Dermot Beirne]

Thanks to you all for your help.
I'll rate the replies on Tuesday when I'm back!
Have a good weekend.
Dermot