)]}'
{
  "log": [
    {
      "commit": "82d5902d9c681be37ffa9d70482907f9f0b7ec1f",
      "tree": "c9c99f0b60004ac14d09d277d3216667df09c32d",
      "parents": [
        "33345d01522f8152f99dc84a3e7a1a45707f387f"
      ],
      "author": {
        "name": "Li Zefan",
        "email": "lizf@cn.fujitsu.com",
        "time": "Wed Apr 20 10:33:24 2011 +0800"
      },
      "committer": {
        "name": "Li Zefan",
        "email": "lizf@cn.fujitsu.com",
        "time": "Mon Apr 25 16:46:11 2011 +0800"
      },
      "message": "Btrfs: Support reading/writing on disk free ino cache\n\nThis is similar to block group caching.\n\nWe dedicate a special inode in fs tree to save free ino cache.\n\nAt the very first time we create/delete a file after mount, the free ino\ncache will be loaded from disk into memory. When the fs tree is commited,\nthe cache will be written back to disk.\n\nTo keep compatibility, we check the root generation against the generation\nof the special inode when loading the cache, so the loading will fail\nif the btrfs filesystem was mounted in an older kernel before.\n\nSigned-off-by: Li Zefan \u003clizf@cn.fujitsu.com\u003e\n"
    },
    {
      "commit": "581bb050941b4f220f84d3e5ed6dace3d42dd382",
      "tree": "5ebd56af5eb3612f508419b188dfc18e959e7c94",
      "parents": [
        "34d52cb6c50b5a43901709998f59fb1c5a43dc4a"
      ],
      "author": {
        "name": "Li Zefan",
        "email": "lizf@cn.fujitsu.com",
        "time": "Wed Apr 20 10:06:11 2011 +0800"
      },
      "committer": {
        "name": "Li Zefan",
        "email": "lizf@cn.fujitsu.com",
        "time": "Mon Apr 25 16:46:04 2011 +0800"
      },
      "message": "Btrfs: Cache free inode numbers in memory\n\nCurrently btrfs stores the highest objectid of the fs tree, and it always\nreturns (highest+1) inode number when we create a file, so inode numbers\nwon\u0027t be reclaimed when we delete files, so we\u0027ll run out of inode numbers\nas we keep create/delete files in 32bits machines.\n\nThis fixes it, and it works similarly to how we cache free space in block\ncgroups.\n\nWe start a kernel thread to read the file tree. By scanning inode items,\nwe know which chunks of inode numbers are free, and we cache them in\nan rb-tree.\n\nBecause we are searching the commit root, we have to carefully handle the\ncross-transaction case.\n\nThe rb-tree is a hybrid extent+bitmap tree, so if we have too many small\nchunks of inode numbers, we\u0027ll use bitmaps. Initially we allow 16K ram\nof extents, and a bitmap will be used if we exceed this threshold. The\nextents threshold is adjusted in runtime.\n\nSigned-off-by: Li Zefan \u003clizf@cn.fujitsu.com\u003e\n"
    }
  ]
}