space incongruency

[Mauro Gatti]

Hi all, it happens in my HP-UX 11.11 this strange fact:

bdf output:

/dev/vg_ods_3/lvother1 3145728 1245000 1885888 40% /u02/oradata/ODS/dbf1

virgo# ls -la /u02/oradata/ODS/dbf1
total 2485120
drwxr-xr-x 3 oracle dba 8192 Apr 27 11:32 .
drwxrwxrwx 5 oracle dba 96 Mar 3 15:20 ..
-rw-r----- 1 oracle oinstall 3858432 Apr 27 11:38 control01.ctl
-rw-rw---- 1 oracle oinstall 209723392 Apr 27 11:38 incarichi_claims01.dbf
drwxr-xr-x 2 root root 96 Jan 23 2003 lost+found
-rw-r--r-- 1 root sys 1000000000 Apr 27 11:32 mauro
-rw-rw---- 1 oracle oinstall 2098208768 Apr 27 11:29 temp2_01.dbf

If I have 3.1GB on /dev/vg_ods_3/lvother1 and I use 3Gb with mauro and temp2_01.dbf file, why bdf reports free 1.8GB?

[Robert-Jan Goossens]

Hi Mauro

????? duh

Could you check the lvol with a fsck ?

Robert-Jan

[V.Tamilvanan]

Hi,

Those files may be open files, oracle process estimated that size and reserved it but physically the data is not written on the disk.

You can check by.

#du -k /u02/oradata/ODS/dbf1

[Mauro Gatti]

du -k /u02/oradata/ODS/dbf1
0 /u02/oradata/ODS/dbf1/lost+found
1242568 /u02/oradata/ODS/dbf1

This is the same thing bdf says:

1242568 blocks * 1024 bytes/block = 1272389632 bytes about 1.2 GB like bdf reports as used.

How is it possible oracle create a file that OS see large a bit but it don't write data on disk?

[A. Clay Stephenson]

Actually that can happen very easily; it's a result of a sparse file.

Consider this:
char x = 'X';
fdes = open("myfile",O_CREAT | O_RDWR,0666);
write(fdes,&x,1);
lseek(fdes,1000000,0);
write(fdes,&x,1);
close(fdes);

This bit of code, creates a new file "myfile" and writes 1 character at offset 0 and then immediately seeks to offset 1000000 and writes 1 char. The result is a file which actually only uses 2 bytes but is 1000000 bytes in length. This is a classic sparse file and it common for applications which allocate large files. To ls -l a size of 1000000 would be reported but to bdf the file would only use 2 blocks. When a file like this is read, the "missing" data is supplied as ASCII NUL characters.

[Mauro Gatti]

Thak You Clive, I start to understend :-)
And now... how can I check "true" used space on filesystem to plan when I have to extend it?
If I can't use bdf and du, is there any other handy way to check space?

Thank You

Mauro

[A. Clay Stephenson · Accepted solution]

Because the internals of "sparse" files are intentionally hidden from all access other than through filesystem internals there is no easy way to do this. One method (though cumbersome) is to backup the data using tar or cpio or fbackup and then restoring it. If you use fbackup/frecover, you do not want to use the -s frecover option because you want sparse files to be filled in. You can also simply copy each file to another temp location and mv it back. Another option is to write a find scripts, extracting regular files and doing an -exec ls -il {} \; and then sorting on the first field (the inode) and only counting the first of duplicate inodes. You then do a second find for directories and do the same thing. Add those totals and you have a very goos approximation of used space. This doesn't count device nodes and pipes but their total usage should be negligible.

If you know Perl, this would be quite easy using File::Find in conjunction with lstat().

[Ashwani Kashyap]

It might be a sparse file . The actually space occupied by the file can be checked with :

du filename
or
ll -s filename .
for eg , you can create a sparse file by doing this :
#dd if=/etc/hosts of =/tmp/sparse bs=1024 seek=1000 .
This will create a 1GB file called sparse in the /tmp directory . ( Beware that the holding directory should have that much space empty .

Now when you do ll /tmp/sparse it will report a 1GB file .

However if you do
du /tmp/sparse or
ll -s /tmp/sparse ,
it will report the actual number of blocks used .