hammer2 - flush sequencing part 1
authorMatthew Dillon <dillon@apollo.backplane.com>
Sat, 4 May 2013 04:31:31 +0000 (21:31 -0700)
committerMatthew Dillon <dillon@apollo.backplane.com>
Sat, 4 May 2013 04:31:31 +0000 (21:31 -0700)
commitd001f460bbf1795b8f37fce7ccc3243202a5d5f6
tree9c277c5bb9be8f494568e15918919d99cb03302b
parenta02dfba1b3bc33418b8e93021ef533f23538f945
hammer2 - flush sequencing part 1

* Rip out the jerry-rigged flush sequencer and start work on a real
  one.

* Sync and fsync calls create synchronization points and will be serialized
  against each other.

* Modifying operations occurring before a synchronization point will stall
  modifying operations occurring after the synchronization point until
  they complete.  This will need to be optimized.

* However, the synchronization points are coded such that modifying operations
  occurring after a synchronization point will be able to run concurrently
  with the disk flush related to that synchronization point.

  So if there is only one synchronization point (sync or fsync or background
  sync) active, modifying operations will generally not stall.  At least not
  for very long.
sys/vfs/hammer2/hammer2.h
sys/vfs/hammer2/hammer2_chain.c
sys/vfs/hammer2/hammer2_flush.c
sys/vfs/hammer2/hammer2_ioctl.c
sys/vfs/hammer2/hammer2_vfsops.c
sys/vfs/hammer2/hammer2_vnops.c