We upgraded one of our F740's from 5.3.7R1 to 6.0.1R3 a week ago. It went very smoothly, but there are a few things still puzzling me. Here is one of them...
Every time a dump command is run, at completion a new file appears in the filer's /etc, with a name like
/etc/oldmaps/bkp/A_home1/3abbe75d | | | \ This is the time(2) of the dump in hex | \ This is the "n" key from the dump command
Peeking at /etc/tmp while dump is running, and comparing inode numbers, it seems that these files are what was /etc/tmp/dump_all.bitmap.[n]. (There are several other files in /etc/tmp, but this seems to be the only one that is saved.) Its size appears to be 1 bit per inode in the volume being dumped, plus a little.
Are these files going to accumulate for ever? None have disappeared as yet, but maybe they will in due course... And what is their purpose in life?
Hey Chris -- Thses files do describe the state of the all the volume's inodes with respect to the tree you're dumping (allocated in this tree or not allocated in this tree). So we need one per tree you dump.
They accumulate -- one for each non-level 0 dump that you do. A level 0 dump will clear them out and leave just the newest one. If you don't use the 'u' option, we don't store the file (since you have declared that you won't be doing an incremental dump based on this dump)
When we base an incremental dump off this base, the bitmaps enable us to find "new files" and "deleted" files better. Now obviously, the file doesn't get you ALL of that information, since an inode can be de-allocated and re-allocated and the map wouldn't know the difference. So we still retain our old code paths as well.
But, basically, we're consuming a little bit of disk space for some performance gain.
If you have any more questions, feel free to ask me.
Stephen Manley DAM and NDMP RC Cola Spokesman/Pop Star