Date: Sun, 10 Nov 1991 18:09:31 +0200
   From: Linus Benedict Torvalds <torvalds@cc.helsinki.fi>

   darken.@cs.yale.edu:
   > 1)  mv doesn't seem to move directories properly.  It looks for
   > something called mvdir and dies.  I want to fix this right away,
   > so I'm goin to start working on it unless one of you drops me a
   > line and explains what stupid thing I've done.

   This is a possibly deficiency in the linux kernel.  I don't allow
   links/unlinks to directories, as keeping track of the parent is too much
   work.  I /think/ it's impossible to allow a hard link to a directory,
   but I'm not sure.  Anybody with ideas is free to mail me. 

Actually, some friends and I spent a lot of time discussing the very
topic tonight.  What we basically got out of it was this:  1) Allowing
links and unlinks to directories are a bad idea; it can potentially
completely ruins the fundamental assumption that the filesystem is a tree.
2) The right way to do this is with the (as yet unimplemented) rename
call.  However there are a number of interesting locking issues that
come when you try to implement this cleanly.

There are a couple problems which rename has to check.  If it is moving
directories around, then the source directory must not be a parent of
the destination directory.  (If it were, there would be no way of
referencing that part of the filesystem after the rename.)  It could
check to make sure this was the case, but unless you actually lock the
directories against another move, there could be a race condition which
could cause the source directory to be a parent of the destination
directory after the check but before the actual reaneme operation, and
bad thing would happen.  There are also other race conditions (not as
sexy) that happen when two processes try to rename a directory at the
same time, and when an rmdir attempts to remove an otherwise empty
destination directory.  

We talked about trying to fix this problem by adding a minimal set of
locks which would be required.  One included just using a top-level lock
on the rename system call, so that only once process could call the
rename() call at any one time.  This solved the problem, but at the
cost of losing parallelism for the rename call.  We also discussed some
other designs, such as locking up to a common ancestor in the tree,
which might also work.

-------------------------------------------------

Speaking of hard disk corruptions, I've found an easy way to get Linux
to corrupt the hard disk.  Simply follow the following instructions:

1)  Copy a large compressed tar file (I used snapshot 312 of
gcc20.tar.Z, found on dg-rtp.dg.com) to your linux disk.  I used kermit
to get it over to my PC and mcopy to get it over to my Linux partition.

2)  Run "compress -d < /tmp/gcc20.tar.Z |tar xvf -"

3)  Afther this completes (it will take a long time), run fsck and
notice that there are alot of unused inodes and zones which are marked
as used, and one or two inodes which marked as being free, but which are
actually being used to point data on them.

4)  Do a "ls -lir" on the new directory created by tar.  This will
almost always cause the kernel to panic: freeing inode: already free. 

I suspect it has something to do with the extreme amount of cache
thrashing that has going on because gcc.tar.Z was a huge file.  I
haven't had a time to look at it, but people should be aware that a
problem exists. 

						- Ted