c21vc@koeddp01.delcoelect.com (Shaker) writes:
: 
: rhh@tachy.uah.ualberta.ca (Roy Hann) writes:
: 
: > wwcoot@lpdwhy.bhp.com.au (Tim Cook) writes:
: > : 
: > : Has anyone out there managed to do on-the-fly compression of Ingres
: > : checkpoints?
: > 
: > Yes.  You want to look at the cktmpl.def file in $II_SYSTEM/ingres/files
: > and read the section of the DBA guide that describes it.  By modifying
: > (and testing it VERY thoroughly) you can do what you want to do.
: > 
: > Here is part of one hack of the cktmpl.def file that worked for me:
: > 
: > WSD:    cd %D; /bin/tar cf - * | compress > %A
: > WRD:    cd %D; mv %A %A.Z; uncompress -c %A | /bin/tar xf -; mv %A.Z %A
: Will the following work ?
: 
: WSD: cd %D; /bin/tar cf - * | compress -v > %A.Z
: WRD:    cd %D; uncompress -c %A | /bin/tar xf -
: 
: The advantage is that the checkpoint files for the different
: locations will have names ending with '.Z' thus making it
: obvious for anyone (doing directory listing for instance) that the
: files are compressed. 

That was what I did in my first attempt.  The problem is that
ckpdb can't find files with a .Z suffix to delete them when you
do a ckpdb -d.  By changing the names in the script like I do
in the example above, everything continues to work normally.

: Let me also go ahead and ask this strictly Unix level question about the
: 'on-the-fly' part:
: 
:  . My understanding is that 'piping' it to compress is what makes it 
:    'on-the-fly' and more efficient (than for instance, compressing the
:    tar files after the checkpoint is complete). How is this accomplished ?

I don't know about "more efficient".  I guess that depends on what
you want to optimize.  In my case I just wanted to conserve space 
because I didn't have much.  By compressing AFTER tar I'd have needed
the extra space required for the uncompressed file, plus the compressed
file.

:    - Doesn't unix still complete the 'tar' part first on all the files
:      before it goes on to the compression or does unix perform the
:      'tar and compress' on a file at a time and the efficiency of
:      'on-the-fly' comes from avoiding disk write after the 'tar' ?

Pipes operate as FIFO devices with an upper limit on how much they
can buffer.  This is not something I am really current on, but I don't
think they can buffer a heck of a lot.  So I think the answer to your
question is that the compression really is occurring on-the-fly, or
very near to it.   That was my justification for trying it in the
first place and it seemed to work as I expected.

--Roy Hann

Ingres Q & A

To William's Home Page

© William Yuan 2000

Email William