)]}'
{
  "commit": "c1631d4a484fbb498e35d661f1aebd64c86b66bf",
  "tree": "06e951cfebbd616dbaa0017d1c030a3f6e0d8d88",
  "parents": [
    "ee149a7c6cbaee0e3a1a7d9e9f92711228ef5236"
  ],
  "author": {
    "name": "Tristan Ye",
    "email": "tristan.ye@oracle.com",
    "time": "Tue May 11 17:54:45 2010 +0800"
  },
  "committer": {
    "name": "Joel Becker",
    "email": "joel.becker@oracle.com",
    "time": "Tue May 18 12:31:05 2010 -0700"
  },
  "message": "Ocfs2: Optimize punching-hole code.\n\nThis patch simplifies the logic of handling existing holes and\nskipping extent blocks and removes some confusing comments.\n\nThe patch survived the fill_verify_holes testcase in ocfs2-test.\nIt also passed my manual sanity check and stress tests with enormous\nextent records.\n\nCurrently punching a hole on a file with 3+ extent tree depth was\nreally a performance disaster.  It can even take several hours,\nthough we may not hit this in real life with such a huge extent\nnumber.\n\nOne simple way to improve the performance is quite straightforward.\nFrom the logic of truncate, we can punch the hole from hole_end to\nhole_start, which reduces the overhead of btree operations in a\nsignificant way, such as tree rotation and moving.\n\nFollowing is the testing result when punching hole from 0 to file end\nin bytes, on a 1G file, 1G file consists of 256k extent records, each record\ncover 4k data(just one cluster, clustersize is 4k):\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n * Original punching-hole mechanism:\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\n   I waited 1 hour for its completion, unfortunately it\u0027s still ongoing.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n * Patched punching-hode mechanism:\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\n   real 0m2.518s\n   user 0m0.000s\n   sys  0m2.445s\n\nThat means we\u0027ve gained up to 1000 times improvement on performance in this\ncase, whee! It\u0027s fairly cool. and it looks like that performance gain will\nbe raising when extent records grow.\n\nThe patch was based on my former 2 patches, which were about truncating\ncodes optimization and fixup to handle CoW on punching hole.\n\nSigned-off-by: Tristan Ye \u003ctristan.ye@oracle.com\u003e\nAcked-by: Mark Fasheh \u003cmfasheh@suse.com\u003e\nSigned-off-by: Joel Becker \u003cjoel.becker@oracle.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "3346e5b199d5e446347716352fe3b5c1d7b7c290",
      "old_mode": 33188,
      "old_path": "fs/ocfs2/file.c",
      "new_id": "9c1047c2e44e2025ebf512768f7197b92271e79d",
      "new_mode": 33188,
      "new_path": "fs/ocfs2/file.c"
    }
  ]
}