Path: utzoo!attcan!uunet!timbuk!cs.umn.edu!msi.umn.edu!src.honeywell.com!uwm.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.admin
Subject: Re: Why idle backups??
Message-ID: <12434:Nov603:25:4290@kramden.acf.nyu.edu>
Date: 6 Nov 90 03:25:42 GMT
References: <1990Oct24.210312.3271@cubmol.bio.columbia.edu> <1990Oc <27337@mimsy.umd.edu>
Organization: IR
Lines: 21

In article <27337@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
> A much simpler method would be to freeze activity on the file system
> being dumped.  A `freezefs' system call is being contemplated.

What would the semantics be? Presumably any process writing to that fs
would be paused in kernel mode until unfreezefs, and the disk would be
synced. Would freezes work like locks, and be released if the process
dies? What about deadlock detection? What happens to kernel writes, to,
e.g., accounting files?

If you're going to have freezefs, why not freezedir? freezefile? Why not
make mandatory write locks available throughout the system? What about
mandatory read locks? Do the applications (e.g., reliable ``find'')
outweigh the risks? Should you only be able to freeze files you own?
Should only root be able to freeze files?

Presumably NFS will muck this up, like mostly everything else. How bad
would the incompatibility be? Would it help if NFS were replaced by a
sane remote file system?

---Dan