Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mtune!codas!killer!richardh
From: richardh@killer.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: UNIX
Message-ID: <1571@killer.UUCP>
Date: Sat, 19-Sep-87 14:37:35 EDT
Article-I.D.: killer.1571
Posted: Sat Sep 19 14:37:35 1987
Date-Received: Sun, 20-Sep-87 16:39:27 EDT
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 66
Keywords: UNIX filesystem fragility
Summary: Unix filesystems and its meta-filesystem

In article <698@pilchuck.Data-IO.COM>, jgray@toad.pilchuck.Data-IO.COM (Jerry Late Nite Gray) writes:
> a software/hardware developer could appriciate. For example could someone
> explain what they mean by a Unix file system being more vulnerable than DOS?
> ---------------
> 					Jerrold L. Gray
> 

In order to improve file i/o performance, Unix buffers all file i/o in the 
kernel. The buffers=xx found in CONFIG.SYS under DOS is an analogous, but much
simpler implementation of the same idea. Except in special cases, when you 
write to a file under Unix, you have no control over when the physical write 
takes place. Needless to say, in a multiple-process, multiple-user environment
there can be a lot of open files and buffered writes in the kernel. If the 
system crashes, not only are all the buffered writes lost, all the open files
may have been left in unknown states. The analog under DOS is crashing and
finding a zero length file in the directory because the directory entry was not 
updated. 

A word about file systems under Unix: the user interface to the disk drives
supports an abstraction of a single hierarchical directory system. There is no
need to specify a physical device as there is under DOS (A:, B:, etc.). All are
accessible under /, the meta-file system's root directory.I call it a meta-file
system to differentiate it from the multiple file systems of which it is 
composed. Each physical device is divided into one or more file systems, each 
of which has the resources allocated to it to be self supporting (analogous
to formatting a disk under DOS which allocates a boot sector, copies of the 
FAT, and the root directory, only you can divide a physical disk into 
multiple "logical" "disks"). Then, you make a file system visible by mounting
it; that is, "connecting" it to the root file system and allowing the kernel
code to set up its own internal resources required to support accessing the
file system.
  
Since you can have multiple file systems under Unix, and all are being managed
in the kernel (at least all the mounted ones), the file systems themselves may
be left in an indeterminate state when the system is brought to an abrupt
halt. Unix must be brought down in an orderly fashion in order to let it leave
the files and filesystems in a known state.
 
However, my experience has been that Unix systems do not crash as
readily as DOS; they trap the offending branch (or whatever) and dump core
instead of crashing. Actually my Unix system (uPort SYS V/AT 2.2.2, on a
12 mhz Wells American) has never crashed. I hit the big red switch once
and watched as fsck (file system check) complained when I powered it back
up, but other than that, I've had no problems. Of course I'm careful to 
bring the system down when I'm ready to quit (or switch over to DOS). 

Ongoing system administration under DOS is very simple. The worst sys admin
problem I've encountered under DOS can be stated as "What am I going to do
with all these damn floppies?" Under Unix, sys admin is a job that can't be
ignored. But then, I suspect it will be under OS/2 also.
 
I'll have to admit that operating a Unix system is more complex than operating
a DOS system. However, I'm not convinced that the complexity is a function of
the os and not of the supported functionality. There are classical os problems
associated with multiple tasks and multiple users (deadlock, race conditions,
resource security, resource sharing) that DOS doesn't have to deal with. Until
I see it, I won't take on faith that OS/2's solutions are any more robust or
elegant than Unix's. However, I will believe that the solutions are more
hardware dependent. It has taken Unix a long time to achieve its high degree
of hardware independence and I can't believe that uSoft/IBM will do so in the 
relatively short period of time that OS/2 has been under development.

regards,
richard hargrove
...!ihnp4!killer!richardh
-------------------------