Archived redo log size reported inconsistently by HPUX

[John Gourlay]

I have an oracle RAC implementation on HPUX 11i and the file system seems to be reporting inconsistent file sizes for archived redo logs. If I use "ls -l" on the root directory of the volume (no significant sub directory data) I see file sizes that when added up are much larger than the volume used from bdf and the disk usage via du. (bdf and du agree as does lstat in an application)

Worst example reported 50MB when du is reporting 17MB.

[A. Clay Stephenson · Accepted solution]

This is generally the result of "sparse" files.
Here is an example of a 2 byte file that occupies 1,000,000 bytes.

char x = 'X';
int n = 0;
off_t offset = 0;

fdes = open("/tmp/myfile",O_CREAT,0666);
n = write(fdes,(void *) &x,sizeof(x));
offset = lseek(fdes,(off_t) 1000000,SEEK_SET);
n = write(fdes,(void *) &x,sizeof(x));
(void) close(fdes);


In the remote chance that you don't speak C, this is an example that writes 1 byte at offset 0; seeks to the 1,000,000th byte offset; and writes 1 more byte.

This would result in ls -l displaying 1000000 but the disk usage (as reported by du and bdf) would be but 2 blocks (not 2 bytes because of the large offset).

Surprisingly, a copy (cp) of this file would actually copy 1000000 bytes, filling in the sparse regions with NUL's.

[John Gourlay]

Excellent this explains our issue.

One other question :

In the example where ll says 50MB and du says 17MB would the 33MB that is not actually used be reserved for this file or is it available to any file on the O/S ? (i.e. is bdf/du reporting true free space on the file system or simply unused space which may actually be reserved ?)

Thanks for your help

[Brian Crabtree]

I have never seen this before (even on RAC). One possiblity is that the log file was generated by a "alter system switch" rather than being switched when full by the archiver.

Thanks,

Brian

[A. Clay Stephenson]

To be accurate, du and bdf are reporting the free space on a filesystem rather than the OS. Sparse files don't actually reserve any space and it's up for grabs by any user/process within that filesystem. In that sense, sparse files allow you to "overbook" just like the airlines. You could copy the files and mv them back to force the space usage -- but the database must be shutdown first. Applications often use sparse files because they can be created and allocated so quickly because the intervening bytes don't have to be written but as you have found there is a "gotcha".