[DRBD-cvs] r1835 - trunk

[www-data]

Author: phil
Date: 2005-07-02 11:52:44 +0200 (Sat, 02 Jul 2005)
New Revision: 1835

Modified:
   trunk/ROADMAP
Log:
A rainy saturday morning. Read a bit in the kernel code...



Modified: trunk/ROADMAP
===================================================================
--- trunk/ROADMAP	2005-07-01 19:20:31 UTC (rev 1834)
+++ trunk/ROADMAP	2005-07-02 09:52:44 UTC (rev 1835)
@@ -495,7 +495,70 @@
 
 20 Make the updates to the bitmap transactional. Esp for resizing.
   Make updates to the superblock transactional
-  
+
+21 Write barriers in the kernel
+  In Linux-2.6 write barriers in the block-io layer are represented as
+  REQ_SOFTBARRIER, REQ_HARDBARRIER and REQ_NOMERGE flags on requests.
+  In the BIO layer this is BIO_RW_BARRIER, which is usually set on
+  BIO_RW (=write) requests.
+
+  The REQ_HARDBARRIER bit is currently used to do a cache flush on 
+  IDE device, which some IDE devices are capable of.
+
+  Journaling file systems should use this barrier mechanism in their journal
+  writes (actually on the commit block, this is the last write in a
+  transactional updated to the jouernal).
+
+  As for DRBD we should probabely ship the REQ_HARDBARRIER flags with
+  our wire protocol (or should they be expressed by Barrier packets?)
+
+  We will only see such REQ_HARDBARRIER flags if state to the upper layers
+  that we are able to deal with them. We need to do this by announcing it:
+  blk_queue_ordered(q, QUEUE_ORDERED_FLUSH or QUEUE_ORDERED_TAG ) .
+  Default ist QUEUE_ORDERED_NODE. This is the reason why we never see
+  the REQ_HARDBARRIER flag currently.
+
+  An other consequence of this is, that IDE devices _not_ support cache
+  flushes and have write cache enabled are inherent buggy to use with
+  a journaled file system.
+
+  What QUEUE_ORDERED_ type should we expose ?
+
+    In order to support capable IDE devices right, we should ship the
+    BIO_RW_BARRIER bit with our data packets in case the peer's backing
+    storage is of the QUEUE_ORDERED_FLUSH type.
+
+    If both devices are of the QUEUE_ORDERED_TAG type should also claim
+    to be of that type, and ship the BIO_RW_BARRIER bit as well.
+
+    self   peer      DRBD
+    ---------------------
+    NONE , NONE  =>  NONE
+    NONE , FLUSH =>  FLUSH  ( for shipping. Strip local. Save ? )
+    NONE , TAG   =>  NONE
+    FLUSH, NONE  =>  FLUSH  ( for local flush. Strip remote. Save ? )
+    FLUSH, FLUSH =>  FLUSH
+    FLUSH, TAG   =>  FLUSH
+    TAG,   NONE  =>  NONE
+    TAG,   FLUSH =>  TAG
+    TAG,   TAG   =>  TAG
+
+  How should we deal with our self generated barrier packets ?
+
+    It looks like that if our backing device's queue properties are set to
+    QUEUE_ORDERED_TAG I guess we might use the RIO_RW_BARRIER flag on BIOs
+    instead of waiting untill all of our pending local write requests are
+    done upon receiving a write barrier packet. This could give us a
+    performance boost.
+
+    In case out backing device only supports QUEUE_ORDERED_FLUSH it is
+    probabely better to use the current code. That mesns, when we receive
+    a write barrier packet we wait until all of our pending local write
+    requests are done.
+
+    In case our backing device is of the QUEUE_ORDERED_NONE class, we
+    have to stay with the current code.
+
 plus-banches:
 ----------------------