NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/sgi/16790

Internet Message Format | 1992-11-23 | 6.8 KB

Path: sparky!uunet!pipex!warwick!uknet!doc.ic.ac.uk!cc.ic.ac.uk!imperial.ac.uk!vulture
From: [e-mail] (Thomas Sippel - Dau)
Newsgroups: comp.sys.sgi
Subject: Re: Indigo as server for a RS600 client - was: NFS links from RS6000 server to SGI client (longish)
Keywords: file system improvements, backup, archive, data interchange
Message-ID: <[e-mail]>
Date: 23 Nov 92 20:26:20 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (Thomas Sippel - Dau)
Reply-To: [e-mail]
Organization: Imperial College of Science, Technology and Medicine
Lines: 172
Nntp-Posting-Host: cscgc

In article <[e-mail]>, [e-mail] (Vernon Schryver) writes:
-
- A process can be running as root on the client, but not be root as far
- as the NFS server is concerned.
-
- You don't really want each and every application including backup or
- archive utility to duplicate the kernel suser() check.  The messiness
- of real, effective, and other flavors of UID and GID are not the sort
- of thing you really want to spread into every application that might be
- called upon to do things that are priviledged.

I quite agree, but ...
.....
-
- Should the backup or archiving utility check to see that it is sufficiently
- priviledged to write ordinary files where directed?  Or should it just
- let the operating system worry about it?

Unfortunately backup and archive utilities are special, and the file system
is also special. New concepts added to the file system will need to be
reflected in archiving utilities, and changes in archiving utilities are
required to work across systems.

Time and again "improvements" to the unix file system have been made without
parallel upgrading of backup utilities. Time and again these utilities
have been "upgraded" to create portable media which cannot be interpreted
by other systems.

According to one of my pet hate lists, this has happened for:

    o   hard links
    o   symbolic links
    o   network access to files
    o   long filenames
    o   long pathnames
    o   pseudo-files (named pipes, streams, sockets, ... )
    o   access control lists
    o   even longer filenames
    o   whole file caching
    o   i-node table limits
    o   file space quotas

With hard links this has already been addressed in the bronze-age of unix,
which is why tar processors on unix will generally not cause information
to be duplicated on the tar set when it contains several links to the same
inode, and restored from there.

This puts us in a neat devil's triangle:

    A   improvements are impossible (have to be working across all systems
        before being allowed on one system)

    B   data interchange is impossible (because of incompatible improvements)

    C   data backup is impossible (as the improvements are either not backed
        up or not portable)

You can avoid one or two of these, but not all three. This happens with
many aspects of computing (or life), it is just that a reliable file
system is so important to use of a computer that makes the choice so
invidious and so difficult to ease.

Manufacturers and other hackers have generally preferred to put in a
modification to the file system and let the user find out how to get
hold of a valid backup of the resulting filesystem, and how to implement
the new concepts with other file system users or on other systems.

There is really no excuse any more not to provide a way to conserve such
file system improvements in a dumpset with codified format (tar and cpio)
so that these can be:

    a.  recreated in the improved form on a system with the
        same processor and the improved concepts

    b.  transferred to a system without improvements, processed by a basic
        tar or cpio format processor, recreated on that system and restored
        with improved conepts intact on an improved system.

Without that, I'm afraid, the old rule applies:

    Small improvements make it worse.

I conclude (yes please ...) with a few examples of particular howlers:

I-node table limits are just now starting to bite users, i.e. the file
system has been hacked to accept more than 2**15 - 1 inodes, but the
appropriate data items in tar have not been uprated. Consequently users
will get additional files (instead of links) if the processor runs out
of table space.

Some manufacturers (who shall be nameless) ship products that cannot be
backed up and restored with the systems backup utility, because a target
of a symbolic link is too long. Is that a broken system, a broken product,
or a broken product development tool and file naming convention ?

Or look at the following fortran program, which creates a temporary file
if necessary, but deletes it only if it had actually itself created it.
Such a code is often necessary in out of core solvers, so that users can
place temporary files on fast access devices or those with enough filespace.

      program clod
      logical ex
      inquire ( file = 'bill', exist = ex )

      if ( ex ) then
        open ( 1, file = 'bill', status = 'old' )
        else
        open ( 1, file = 'bill', status = 'new' )
        endif

      write ( 1, '(a)' ) 'you clod'

      if ( ex ) then
        print *, 'bill existed, keeping it'
        close ( 1, status = 'keep' )
        else
        print *, 'bill did not exist, will delete it'
        close ( 1, status = 'delete' )
        endif

      stop
      end

On unix it may fail because of a the way the richness of file system
facilities has been mapped into the limited set of fortran file concepts,
as follows:

carrion$ f77 clod.f
carrion$ rm fred bill
rm: bill non-existent
carrion$ a.out
 bill did not exist, will delete it
carrion$ ls -l fred bill
fred: No such file or directory
bill: No such file or directory
carrion$ ln -s fred bill
carrion$ a.out
 bill did not exist, will delete it
carrion$ cat fred
you clod

The reaction of an incredibly big manufacturer of a fortran compilers to
a related problem with the "exist" keyword of "inquire" started with:

The Fortran Standard refers to files not datasets ...
         (I won't bore you with the details)

Editors trying to do atomic updates (by writing to a temporary file and
renaming it) have been flattened again and again by additional concepts.
The Andrew File System discussion groups are full of corpses like that.
And with Windows, every application is an editor (for the user preference
settings).
                                Thomas
--
*** This is the operative statement, all previous statements are inoperative.
*   email: cmaae47 @ ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic on Janet)
*   voice: [phone] x4937 or 4934 (day), or [phone] (fax)
*   snail: Imperial College of Science, Technology and Medicine
*   The Center for Computing Services, Kensington SW7 2BX, Great Britain