Changes by: erm (erm at unknown.email)
Date: 2004-08-11 19:28:52 -0700 (Wed, 11 Aug 2004)
Revision: 1835
Log message:

      All the files for the new distributed file system.
      
      Currently dufs compiles and will do a few operations correctly: read, write,
      list files, modify inodes, maybe some others.  Creating/removing files is still
      a problem.
      
      Things get confused if the server dies, the uservfs system is unmounted out from
      under it, or sometimes if files change in the underlying directory.  I'm not
      sure if any of that counts as real bugs, though :)
      

Changes by: erm (erm at unknown.email)
Date: 2004-08-11 19:28:54 -0700 (Wed, 11 Aug 2004)
Revision: 1836
Log message:

      All the files for the new distributed file system.
      
      Currently dufs compiles and will do a few operations correctly: read, write,
      list files, modify inodes, maybe some others.  Creating/removing files is still
      a problem.
      
      Things get confused if the server dies, the uservfs system is unmounted out from
      under it, or sometimes if files change in the underlying directory.  I'm not
      sure if any of that counts as real bugs, though :)
      

Changes by: erm (erm at unknown.email)
Date: 2004-08-19 17:18:29 -0700 (Thu, 19 Aug 2004)
Revision: 1837
Log message:

      Small programs and scripts I wrote to help test the uservfs system and my
      code.
      

Changes by: erm (erm at unknown.email)
Date: 2004-08-19 17:20:03 -0700 (Thu, 19 Aug 2004)
Revision: 1838
Log message:

      Don't want to cvsify object files and other cruft...
      

Changes by: erm (erm at unknown.email)
Date: 2004-08-19 17:33:47 -0700 (Thu, 19 Aug 2004)
Revision: 1839
Log message:

      Fixed a number of show-stopper quality bugs with Cristian's help:
      --Large number of files => massive weirdness:
          I wasn't closing the directory handle in the ML mirrorfs read_dir
          function.
      --All writes start at position zero, regardless of syscall parameters:
          There was no code in the uservfs module to increase the file pointer on
          a write file op.
      --Directory listings return only a fraction of the present files:
          A line (module/uservfs_dir.c:142) was missing to decrement the index...
          It makes more sense--sort of--if you look at the code.
      
      Still problematic:
      --I've had two kernel panics during testing.  They've both been in kernel
        code not related at all to the modules (scheduler and an illegal operation
        in an interrupt) which makes me suspect a race condition knocking around
        somewhere in the uml code, but I really don't know.
      --Speed?  I haven't run any tests at all, but it's not going to win any
        awards.  Turning off the huge amount of debugging spew helps, though.
      --Symlinks still don't work.  Symlinks really should work on a production
        filesystem, but for development and testing, not such a big deal.  Dunno
        about hard links yet, but I don't know why they wouldn't work.
      --There are random oddnesses about the root inode permissions that I don't
        comprehend in the least.  That's not important at all, though--we work
        inside a subdir of the root always, and we're fine there.
      

Changes by: erm (erm at unknown.email)
Date: 2004-08-19 18:24:39 -0700 (Thu, 19 Aug 2004)
Revision: 1840
Log message:

      Woo! Documentation.  More to follow.