deactivate sparse files

[George Barbitsas]

Is there a way to deactivate sparse files on a hpux 11.11 server using vxfs underlying filesystem?? We are having problems with some table spaces in oracle

[Yogeeraj_1 · Accepted solution]

hi,

Please clarify. How could the existance of the sparse file affect some of your tablespaces?

Normally for a sparse file (e.g. when you create a temporary tablespace with the tempfile option), the OS really allocate space to the file only when you write to it.

One of the nuances of true temporary files is that if the operating system permits it, the temporary files will be created as sparse. That is, they will not actually consume disk storage until they need to.

To prevent this, some of the options are to use dd to fill the file or use cp to create a non-sparse file.

"sparse file" is considered to be is a unix feature!!


if you need any further clarification, let us know.

kind regards
yogeeraj

[George Barbitsas]

The basis team wants to know if there is anyway to deactivate this feature in VXFS or hpux LVM...apparently they could get around that by recreating the tablespace but they have 101 oracle databases to patch in this case....I myself could not find a documented way to deactivate that from the OS perspective...I did come across the parameter fixed_size using vxtunefs but not sure if its relevant to sparse files.

ThX

[A. Clay Stephenson]

There is no way to deactivate sparse files nor is there any need to do so. The sparseness of a file is completely invisible to any application. When a read() is done on a file with "holes", the holes are silently and invisibly filled with ASCII NUL's. The application doesn't have a clue that anything is different. You can do any test you like (e.g. cksum); sparse and equivalent non-sparse files will report the same values. In fact, even backup programs can't tell that a sparse files is sparse although restore programs can restore sparse files. How? When restoring files, if a number of adjacent ASCII NUL's are detected, the restore program can write() a single NUL, issue an lseek() to skip past the remaining NUL's, and then write() a non-NUL byte. It should be obvious that while it is possible to restore sparse files, it is extremely improbable that the "holes" will be recreated in exactly the same way as the originally backed up file.

In any event, you can convert any sparse file to non-sparse by cp'ing it to a temporary file and then mv'ing the temporary file to the original but there is no reason to do this.

The only danger that a sparse file causes is a potential over-commitment of a filesystem. It is possible that a filesystem might contain enough sparse files that should they all be "filled in", the filesystem would run out of room. This is analogous to airline over-booking. Unless you have seen that situation, whatever your DBA's think is the problem, it ain't sparse files.

[George Barbitsas]

ok thanks for the info

[George Barbitsas]

found solution

[Dennis Handly]

>Clay: In any event, you can convert any sparse file to non-sparse by cp'ing it to a temporary file and then mv'ing the temporary file

Doesn't the read of the original file fill in the sparse file? Or is the file system smart enough to fill in the buffer with zeroes?

[Hein van den Heuvel]

Dennis>> "Doesn't the read of the original file fill in the sparse file?"

No.

Eric,

Care to share that solution for the benefit of future readers?

Not that I believe there to be good enough reasons to want to do this, but just in case.

Mind you, there are several reasons why you might want to do this.

Writing any block for the first time in a sparse file will cause overhead, as the extents must still be allocated by the file. This can be compounded by `smart' IO controllers, like the 'EVA' which also postpone allocating storage segments until a first block is actually written.

That overhead is happen at a time you actually might need the performance. Whereas often the performance of the creation of a new temp space is not at all critical and perhpas done outside main business hours.

Those sparse files can cause unpredictable performance result, which can make benchmark tasks poorly repeatable.

They can also cause excessive fragmentation.

Finally I believe this can cause overcommitment of resources. The sparse file may lead you to believe there are still ample free blocks on the device. You put an other datafile for an other datafile there and then hours or weeks later when more TEMP space is used you suddenly, unexpectedly, and unacceptably, run out of disk space!?

Really, now that I listed all that came to mind, I have to agree with the notion of wanting to disable them! So little to gain, so much to loose?

Hope this helps someone, somewhere, some time,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting