hammer2 - performance, stabilization
authorMatthew Dillon <dillon@apollo.backplane.com>
Wed, 6 Nov 2013 06:49:44 +0000 (22:49 -0800)
committerMatthew Dillon <dillon@apollo.backplane.com>
Wed, 6 Nov 2013 06:49:44 +0000 (22:49 -0800)
commit3f5b8b3b1546a3803bad2d997deefa0f4e30549d
treefb550b97a2fba7438bc04c63bc0ca9f881d063f6
parentf567e034c99a8bbc2589df8e66f496a340f22c39
hammer2 - performance, stabilization

* Add hysteresis to anything calling H2's strategy functions.  Because
  the BIOs are queued to a thread and compression might be required,
  it is possible for buffer flushes to queue thousands of BIOs to the
  thread all at once.  This can result in thousands of locked BUFs which
  then stall frontend code.

  Stall strategy calls (typically the buffer flush code) after queueing
  a BIO when the number of pending file BIOs exceeds vfs.hammer2.flush_pipe,
  whos value defaults to 100.  Hysteresis is set at 3/4ths the value so
  a maximum efficiency pipeline is maintained.

* Do not try to update blockrefs in an inode when the inode is flagged
  DIRECTDATA.  This case can occur when a hardlink is shifted up to a
  higher directory.  The original inode is converted into an OBJT_HARDLINK
  object which has no file data.  Fixes a panic.
sys/vfs/hammer2/hammer2.h
sys/vfs/hammer2/hammer2_flush.c
sys/vfs/hammer2/hammer2_vfsops.c
sys/vfs/hammer2/hammer2_vnops.c