neil@group-id.co.uk (Neil Todd) (05/25/90)
This warning may save you a small amount of grief. You should certainly read it if you intend to put multiple dumps on a massively caching dump device - e.g. an exabyte. There is a problem with BSD style dump, it decides that it has finished successfully before doing the final close() on the output device, worse still it ignores that value returned by close(). So, you get the dumpdates file updated, a "Dump is Done" and an exit status of zero before it is 100% sure that the close() (and presumably pending writes) worked. An example helps, suppose that you are putting a series of over night incremental dumps onto one Exabyte tape, and the last dump is just a little too big for the tape. Because of caching by the machine and the Exabyte all the data, as far as dump is concerned, gets written away. Your operator checks the dump logs the next morning, all seems fine. Nobody notices some scsi sense errors on the console or in the messages file - or if they do, they fail to think that anything is wrong with the dump - after all the log said that is finished ok. You only discover your problem when you come to restore, and by then it may be too late.... We picked it up very quickly here because we do a "restore -vt" of each dump as part of the dumping script. The message 'Not a dump' came out for the final dump on the tape. This problem with dump stems from an error in the original BSD dump, can can be fixed by reordering about three lines of code + checking the return value for the final close (look in dumpmain.c, I think). Neil Todd | ..In general, it is best to assume that the PSI%234237100122::neil | network is filled with malevolent entities neil@gid.co.uk | that will send in packets designed to have Group-ID Ltd | the worst possible effect...