Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!inuxc!iuvax!bsu-cs!rb442!dhesi From: dhesi@rb442.UUCP Newsgroups: comp.unix.wizards Subject: Re: Backups on Live Systems Message-ID: <105@rb442.UUCP> Date: Wed, 10-Jun-87 00:31:33 EDT Article-I.D.: rb442.105 Posted: Wed Jun 10 00:31:33 1987 Date-Received: Sat, 13-Jun-87 04:12:43 EDT References: <132@dvm.UUCP> <725@aramis.rutgers.edu> <20070@sun.uucp> <6279@pur-ee.UUCP> <2990@cit-vax.Caltech.Edu> Reply-To: dhesi@rb442.UUCP (Rahul Dhesi) Organization: CS Dept., Ball State University, Muncie, Indiana Lines: 30 In article <2990@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (System Mangler) writes: >In article <6279@pur-ee.UUCP>, davy@pur-ee.UUCP (Dave Curry) writes: [discussing how to deal with files that change during a dump] >> Basically, these mods >> tell dump to ignore any inode which has changed since the dump started. >> This has the minor disadvantage that some files (those being modified) >> will be missing from the dump ... >It doesn't hurt for the file to be modified while >dump isn't looking (so long as it stays the same type); what hurts >is when the file is modified in the middle of being dumped, something >you don't detect and can't do anything about even if you detected it >(other than warn the operator to start over). The perfect solution is not difficult, though it will probably attract a lot of flames. The good folks at BBN Inc. invented it many years ago. They called it copy-on-write. They used it to allow self-modifying programs to be shareable. We can use it to dump active filesystems. It will need some kernel changes. Before you begin dumping a file, you mark it copy-on-write. During the dump, any attempt to write to the file doesn't change the original but always allocates a new block. The dump process sees only the original unchanged file. The process writing to the file sees only the new modified file. -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi