Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!bu.edu!orc!inews!iwarp.intel.com!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.admin
Subject: Re: Why idle backups??
Message-ID: <1990Nov07.154025.28695@chinet.chi.il.us>
Date: 7 Nov 90 15:40:25 GMT
References: <1990Oc <27337@mimsy.umd.edu> <12434:Nov603:25:4290@kramden.acf.nyu.edu>
Organization: Chinet - Public Access UNIX
Lines: 41

In article <12434:Nov603:25:4290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>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?

A more pleasant scenario would be to have a 'readfrozen' system call
as well to bypass the common disk buffer cache which would be allowed
to grow and page into swap space for the duration.  'Unfreezefs' would
then perform a sync, collapsing the cache back to its normal size.
Other processes would not need to pause unless the swap space becomes
full. Some care would have to be taken to avoid pausing the program
that issued the freezefs call in this situation, but that doesn't sound
impossible.
 
>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?

Freezedir would be pretty messy since you would essentially have to do
a "find" as an atomic operation.  Freezefile(list_of_files or inodes)
would suffice for the usual problem of getting a consistent snapshot
of a multi-file database, although only the application writing them
would know the proper time to issue the call (this, of course applies
to freezefs as well and is probably the reason nobody bothers doing it).
SysVr3 has the mandatory locking scheme - has anyone used it?

>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?

Wouldn't freezefs have to be provided at the server end? 

Les Mikesell
  les@chinet.chi.il.us