)]}'
{
  "commit": "961902c0f8240175729274cd14198872f42072b7",
  "tree": "808b47d32174e970465dc00cea9150ff978bfc95",
  "parents": [
    "60fc13702a1b35118c1548e9c257fa038cecb658"
  ],
  "author": {
    "name": "NeilBrown",
    "email": "neilb@suse.de",
    "time": "Fri Dec 23 09:57:48 2011 +1100"
  },
  "committer": {
    "name": "NeilBrown",
    "email": "neilb@suse.de",
    "time": "Fri Dec 23 09:57:48 2011 +1100"
  },
  "message": "md/bitmap: It is OK to clear bits during recovery.\n\ncommit d0a4bb492772ce5c4bdfba3744a99ed6f6fb238f introduced a\nregression which is annoying but fairly harmless.\n\nWhen writing to an array that is undergoing recovery (a spare\nin being integrated into the array), writing to the array will\nset bits in the bitmap, but they will not be cleared when the\nwrite completes.\n\nFor bits covering areas that have not been recovered yet this is not a\nproblem as the recovery will clear the bits.  However bits set in\nalready-recovered region will stay set and never be cleared.\nThis doesn\u0027t risk data integrity.  The only negatives are:\n - next time there is a crash, more resyncing than necessary will\n   be done.\n - the bitmap doesn\u0027t look clean, which is confusing.\n\nWhile an array is recovering we don\u0027t want to update the\n\u0027events_cleared\u0027 setting in the bitmap but we do still want to clear\nbits that have very recently been set - providing they were written to\nthe recovering device.\n\nSo split those two needs - which previously both depended on \u0027success\u0027\nand always clear the bit of the write went to all devices.\n\nSigned-off-by: NeilBrown \u003cneilb@suse.de\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "b6907118283a627a656fbe408e368da9853ff634",
      "old_mode": 33188,
      "old_path": "drivers/md/bitmap.c",
      "new_id": "6d03774b176ec8236d9cfb72654bedf600f052d2",
      "new_mode": 33188,
      "new_path": "drivers/md/bitmap.c"
    }
  ]
}
