)]}'
{
  "commit": "75f187aba5e7a3eea259041f85099029774a4c5b",
  "tree": "34a26995689413e123463300447f2e0fb7b05673",
  "parents": [
    "cd89f46b52cd2354d3d322ea7eab193b86ba03c6"
  ],
  "author": {
    "name": "Alex Bligh",
    "email": "alex@alex.org.uk",
    "time": "Wed Feb 27 17:05:23 2013 -0800"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Wed Feb 27 19:10:22 2013 -0800"
  },
  "message": "nbd: support FLUSH requests\n\nCurrently, the NBD device does not accept flush requests from the Linux\nblock layer.  If the NBD server opened the target with neither O_SYNC nor\nO_DSYNC, however, the device will be effectively backed by a writeback\ncache.  Without issuing flushes properly, operation of the NBD device will\nnot be safe against power losses.\n\nThe NBD protocol has support for both a cache flush command and a FUA\ncommand flag; the server will also pass a flag to note its support for\nthese features.  This patch adds support for the cache flush command and\nflag.  In the kernel, we receive the flags via the NBD_SET_FLAGS ioctl,\nand map NBD_FLAG_SEND_FLUSH to the argument of blk_queue_flush.  When the\nflag is active the block layer will send REQ_FLUSH requests, which we\ntranslate to NBD_CMD_FLUSH commands.\n\nFUA support is not included in this patch because all free software\nservers implement it with a full fdatasync; thus it has no advantage over\nsupporting flush only.  Because I [Paolo] cannot really benchmark it in a\nrealistic scenario, I cannot tell if it is a good idea or not.  It is also\nnot clear if it is valid for an NBD server to support FUA but not flush.\nThe Linux block layer gives a warning for this combination, the NBD\nprotocol documentation says nothing about it.\n\nThe patch also fixes a small problem in the handling of flags: nbd-\u003eflags\nmust be cleared at the end of NBD_DO_IT, but the driver was not doing\nthat.  The bug manifests itself as follows.  Suppose you two different\nclient/server pairs to start the NBD device.  Suppose also that the first\nclient supports NBD_SET_FLAGS, and the first server sends\nNBD_FLAG_SEND_FLUSH; the second pair instead does neither of these two\nthings.  Before this patch, the second invocation of NBD_DO_IT will use a\nstale value of nbd-\u003eflags, and the second server will issue an error every\ntime it receives an NBD_CMD_FLUSH command.\n\nThis bug is pre-existing, but it becomes much more important after this\npatch; flush failures make the device pretty much unusable, unlike\n\nSigned-off-by: Paolo Bonzini \u003cpbonzini@redhat.com\u003e\nSigned-off-by: Alex Bligh \u003calex@alex.org.uk\u003e\nAcked-by: Paul Clements \u003cPaul.Clements@steeleye.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "ade146bf65e527ea9db3a9b8835bc252a4f58472",
      "old_mode": 33188,
      "old_path": "drivers/block/nbd.c",
      "new_id": "695c68fedd329623250de5376a198a4f43b67c8d",
      "new_mode": 33188,
      "new_path": "drivers/block/nbd.c"
    },
    {
      "type": "modify",
      "old_id": "dfb514472cbc49d64712112c1cd3d042c56cfb0f",
      "old_mode": 33188,
      "old_path": "include/uapi/linux/nbd.h",
      "new_id": "4f52549b23ff8765e0c5cfcf599190eca897de87",
      "new_mode": 33188,
      "new_path": "include/uapi/linux/nbd.h"
    }
  ]
}