cvs commit: src/sys/vfs/hammer hammer.h hammer_blockmap.c hammer_flusher.c hammer_inode.c hammer_io.c hammer_object.c hammer_ondisk.c hammer_undo.c hammer_vfsops.c

[Michael Neumann]

Matthew Dillon wrote:
dillon      2008/07/17 17:19:53 PDT

DragonFly src repository

  Modified files:
    sys/vfs/hammer       hammer.h hammer_blockmap.c 
                         hammer_flusher.c hammer_inode.c 
                         hammer_io.c hammer_object.c 
                         hammer_ondisk.c hammer_undo.c 
                         hammer_vfsops.c 
  Log:
  HAMMER 63/Many: IO Error handling features
  
  This commit removes all the remaining Debugger() calls and KKASSERTs in the
  I/O error path.  Errors are now propagated up the call tree and properly
  reported.
  
  * Report I/O errors instead of asserting.
  
  * Read or Write errors in the flush path disable flushing and force the mount
    into read-only mode.  Modified buffers are left locked in memory until
    umount to provide a consistent snapshot of the state of the filesystem.
What would happen if the system runs out of memory? Will it die due to
memory allocation issues, or will it detect that it is low on memory and
return filesystem related errors.
    You must umount and remount to recover the filesystem.  The filesystem
    will automatically rollback to the last valid flush upon remounting.
That means, if I umount, I loose all the changes made on the locked
in-memory buffers, right?
  * umount and umount -f are now able to unmount a HAMMER filesystem that has
    catastrophic write errors (e.g. pulling the USB cable on an external
    drive).
Cool, even though I am hoping not to come in a situation where this will
be neccessary ;-)
Regards,

  Michael