Conference decwet::advfs_support

    Hi,
    
    Just to keep this stream up to date:
    
    The NetWorker (V4.2A) release notes explain that NSR is detecting the
    "sparse" files by comparing the byte length of the file (ls -l) and the
    blocks used by the file (du -k). If the byte length (converted in 1k
    blocks) is greater than the block count, NSR declares that file as a
    sparse file. So far, so well...
    
    But, NSR is reading the file to save it on tape, and when it reads the
    "hole" part of the file, it just receives blocks of null code. So far,
    so well...
    
    To correctly identify the holes during the save, NSR is "translating"
    the long sequence of null codes in its internal representation of
    "holes". So, at the restore time, the file can be correctly restore
    with its original holes. So far, so well...
    
    Now, the problem: when "du -k" is executed on an ADVFS clone, it reports
    the number of blocks really allocated to the clone (or if you prefer,
    the number of "changed" blocks in the original fileset), so ALL THE
    FILES APPEARS as SPARSE FILES TO NSR. 
    
    And, as NSR is translating the long sequence of null code into "holes",
    databases containing a lot of null-initialized areas are NOT BACKUP'ed
    as they are really but with holes.
    
    In other words, there is an obvious lack of integration between NSR and
    ADVFS, and we MUST forget ADVFS clones when using NSR... :-)
    
    Manu.
    

I don't think this question really belongs in this string
So if you want to discuss it further, please open a new
string.
If DECnsr doesn't figure out sparseness the same way
vdump does (by using the actual extent maps) then it will
not satisfy databases that pre-allocate blocks of zeroes
for performance reasons. I'd hope you'd follow up on that
with them. 
As discussed elsewhere in this conference, vdump uses the
maps when backing up advfs files and this allows it to
save time reading the target file, and writing to the
archive. Then later it allows a vrestore to replace the
sparseness in the same places it found it (and restores
blocks of zeroes that weren't actually sparseness).

    Thanks for your answer!
    
    You said that the discussion switch suddently to sparseness...
    
    Not exactly. I am speaking about backuping ADVFS clones on DECnsr.
    There is a lot of answers in this note stream about "BACKUP" of "CLONE"
    of "ORACLE" databases. If you are doing backups of CLONES of ORACLE
    databases then (according to the NetWorker realease notes)  you are
    very subject that your databases will be restore with "holes" which is
    NOT acceptable if they were NOT SPARSE at the backup time. The
    NetWorker release notes say that it will change with a "NEXT ADVFS"
    release. I was just trying to explain how and why  NetWorker and ADVFS
    are not understanding each other.
    
    You can say that NetWorker is responsible, NetWorker can say that ADVFS
    is responsible and WE in the field can simply return to "dump" and
    "UFS" and explain to our customer that these Engineering groups are not
    speaking to each other. 
    
    >>>    Please, try to better integrate the Digital products !!!     <<<
    
    Manu.