Re: 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 <mneumann@xxxxxxxx>]

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