This question came to me from Rune (his question is edited for brevity):
I’ve got a SLES 9.3 system where the users are using gzip to compress their daily online DB backups. It’s scripted, but basically it goes something like this:
# dbbackup db1 /scratch/outputfile1
# gzip /scratch/outputfile1
# dbbackup db1 /scratch/outputfile2
# gzip /scratch/outputfile2
[…He goes on to explain that the backup fills up the filesystem, especially since some aspect of the process/filesystem is holding on to the space long after the db output….]
Do you know if this is expected behavior for gzip? […]
Yes, that can be normal, but it isn’t gzip‘s fault. It could be the filesystem and kernel together, and could be the storage system you use (you didn’t mention if it is a SAN, but it sure sounds like it could be SAN behavior). The space is allocated as needed, but cleanup routines run to clear the actual space later. That’s pretty low-level stuff, and I don’t want to get into it here… especially since I don’t know the specifics without researching it… š
One way to avoid the whole problem though, is to dump the database backup output inline into gzip; instead of making the file, and *then* zipping it. That way, the only space that is allocated is the space needed the first time. You don’t end up having waiting for a cleanup after the export and before the gzip.
I’m glad you included your script element so I could offer a suggestion… try this:
dbbackup db1 |gzip > /scratch/outputfile1.zip
…hope that helps!
š