)]}'
{
  "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"
    },
    {
      "commit": "34d52cb6c50b5a43901709998f59fb1c5a43dc4a",
      "tree": "151c61795cceefc97e48e8209dc36303274fbe10",
      "parents": [
        "f38b6e754d8cc4605ac21d9c1094d569d88b163b"
      ],
      "author": {
        "name": "Li Zefan",
        "email": "lizf@cn.fujitsu.com",
        "time": "Tue Mar 29 13:46:06 2011 +0800"
      },
      "committer": {
        "name": "Li Zefan",
        "email": "lizf@cn.fujitsu.com",
        "time": "Mon Apr 25 16:46:03 2011 +0800"
      },
      "message": "Btrfs: Make free space cache code generic\n\nSo we can re-use the code to cache free inode numbers.\n\nThe change is quite straightforward. Two new structures are introduced.\n\n- struct btrfs_free_space_ctl\n\n  We move those variables that are used for caching free space from\n  struct btrfs_block_group_cache to this new struct.\n\n- struct btrfs_free_space_op\n\n  We do block group specific work (e.g. calculation of extents threshold)\n  through functions registered in this struct.\n\nAnd then we can remove references to struct btrfs_block_group_cache.\n\nSigned-off-by: Li Zefan \u003clizf@cn.fujitsu.com\u003e\n"
    },
    {
      "commit": "92c423118105e1c8c1587367a26eeb3277bda89a",
      "tree": "fff00ab60c0e2b82b0ab5a997ce311e13390bfa9",
      "parents": [
        "f65647c29b14f5a32ff6f3237b0ef3b375ed5a79"
      ],
      "author": {
        "name": "Li Zefan",
        "email": "lizf@cn.fujitsu.com",
        "time": "Wed Mar 02 16:50:21 2011 +0800"
      },
      "committer": {
        "name": "Li Zefan",
        "email": "lizf@cn.fujitsu.com",
        "time": "Mon Apr 25 16:45:59 2011 +0800"
      },
      "message": "Btrfs: Remove unused btrfs_block_group_free_space()\n\nWe\u0027ve already recorded the value in block_group-\u003efrees_space.\n\nSigned-off-by: Li Zefan \u003clizf@cn.fujitsu.com\u003e\n"
    },
    {
      "commit": "f7039b1d5c32241f87a513e33120db36bf30264d",
      "tree": "e911bc79c795fceb3e9a618d8f18571c2a776307",
      "parents": [
        "5378e60734f5b7bfe1b43dc191aaf6131c1befe7"
      ],
      "author": {
        "name": "Li Dongyang",
        "email": "lidongyang@novell.com",
        "time": "Thu Mar 24 10:24:28 2011 +0000"
      },
      "committer": {
        "name": "root",
        "email": "Chris Mason chris.mason@oracle.com",
        "time": "Mon Mar 28 05:37:47 2011 -0400"
      },
      "message": "Btrfs: add btrfs_trim_fs() to handle FITRIM\n\nWe take an free extent out from allocator, trim it, then put it back,\nbut before we trim the block group, we should make sure the block group is\ncached, so plus a little change to make cache_block_group() run without a\ntransaction.\n\nSigned-off-by: Li Dongyang \u003clidongyang@novell.com\u003e\nSigned-off-by: Chris Mason \u003cchris.mason@oracle.com\u003e\n"
    },
    {
      "commit": "9d66e233c7042da27ec699453770f41e567a0442",
      "tree": "27fd70c6c07cb96a48123bdec07e9c2feed90f13",
      "parents": [
        "0cb59c9953171e9adf6da8142a5c85ceb77bb60d"
      ],
      "author": {
        "name": "Josef Bacik",
        "email": "josef@redhat.com",
        "time": "Wed Aug 25 16:54:15 2010 -0400"
      },
      "committer": {
        "name": "Chris Mason",
        "email": "chris.mason@oracle.com",
        "time": "Fri Oct 29 09:26:35 2010 -0400"
      },
      "message": "Btrfs: load free space cache if it exists\n\nThis patch actually loads the free space cache if it exists.  The only thing\nthat really changes here is that we need to cache the block group if we\u0027re going\nto remove an extent from it.  Previously we did not do this since the caching\nkthread would pick it up.  With the on disk cache we don\u0027t have this luxury so\nwe need to make sure we read the on disk cache in first, and then remove the\nextent, that way when the extent is unpinned the free space is added to the\nblock group.  This has been tested with all sorts of things.\n\nSigned-off-by: Josef Bacik \u003cjosef@redhat.com\u003e\n"
    },
    {
      "commit": "0cb59c9953171e9adf6da8142a5c85ceb77bb60d",
      "tree": "f72af47fa18815491814290a1b4907082bd9316d",
      "parents": [
        "0af3d00bad38d3bb9912a60928ad0669f17bdb76"
      ],
      "author": {
        "name": "Josef Bacik",
        "email": "josef@redhat.com",
        "time": "Fri Jul 02 12:14:14 2010 -0400"
      },
      "committer": {
        "name": "Chris Mason",
        "email": "chris.mason@oracle.com",
        "time": "Fri Oct 29 09:26:29 2010 -0400"
      },
      "message": "Btrfs: write out free space cache\n\nThis is a simple bit, just dump the free space cache out to our preallocated\ninode when we\u0027re writing out dirty block groups.  There are a bunch of changes\nin inode.c in order to account for special cases.  Mostly when we\u0027re doing the\nwriteout we\u0027re holding trans_mutex, so we need to use the nolock transacation\nfunctions.  Also we can\u0027t do asynchronous completions since the async thread\ncould be blocked on already completed IO waiting for the transaction lock.  This\nhas been tested with xfstests and btrfs filesystem balance, as well as my ENOSPC\ntests.  Thanks,\n\nSigned-off-by: Josef Bacik \u003cjosef@redhat.com\u003e\n"
    },
    {
      "commit": "0af3d00bad38d3bb9912a60928ad0669f17bdb76",
      "tree": "abbf4c773138a33dcde483ac60f016c4b5e55dcc",
      "parents": [
        "f6f94e2ab1b33f0082ac22d71f66385a60d8157f"
      ],
      "author": {
        "name": "Josef Bacik",
        "email": "josef@redhat.com",
        "time": "Mon Jun 21 14:48:16 2010 -0400"
      },
      "committer": {
        "name": "Josef Bacik",
        "email": "josef@redhat.com",
        "time": "Thu Oct 28 15:59:09 2010 -0400"
      },
      "message": "Btrfs: create special free space cache inode\n\nIn order to save free space cache, we need an inode to hold the data, and we\nneed a special item to point at the right inode for the right block group.  So\nfirst, create a special item that will point to the right inode, and the number\nof extent entries we will have and the number of bitmaps we will have.  We\ntruncate and pre-allocate space everytime to make sure it\u0027s uptodate.\n\nThis feature will be turned on as soon as you mount with -o space_cache, however\nit is safe to boot into old kernels, they will just generate the cache the old\nfashion way.  When you boot back into a newer kernel we will notice that we\nmodified and not the cache and automatically discard the cache.\n\nSigned-off-by: Josef Bacik \u003cjosef@redhat.com\u003e\n"
    },
    {
      "commit": "963030817060e4f109be1993b9ae8f81dbf5e11a",
      "tree": "7d81121b7e68d3d5b3317afba53d36bc1bf8221a",
      "parents": [
        "83121942b28daffc9526b14b7843d8cdbd3db641"
      ],
      "author": {
        "name": "Josef Bacik",
        "email": "josef@redhat.com",
        "time": "Mon Jul 13 21:29:25 2009 -0400"
      },
      "committer": {
        "name": "Chris Mason",
        "email": "chris.mason@oracle.com",
        "time": "Fri Jul 24 09:23:30 2009 -0400"
      },
      "message": "Btrfs: use hybrid extents+bitmap rb tree for free space\n\nCurrently btrfs has a problem where it can use a ridiculous amount of RAM simply\ntracking free space.  As free space gets fragmented, we end up with thousands of\nentries on an rb-tree per block group, which usually spans 1 gig of area.  Since\nwe currently don\u0027t ever flush free space cache back to disk this gets to be a\nbit unweildly on large fs\u0027s with lots of fragmentation.\n\nThis patch solves this problem by using PAGE_SIZE bitmaps for parts of the free\nspace cache.  Initially we calculate a threshold of extent entries we can\nhandle, which is however many extent entries we can cram into 16k of ram.  The\nmaximum amount of RAM that should ever be used to track 1 gigabyte of diskspace\nwill be 32k of RAM, which scales much better than we did before.\n\nOnce we pass the extent threshold, we start adding bitmaps and using those\ninstead for tracking the free space.  This patch also makes it so that any free\nspace thats less than 4 * sectorsize we go ahead and put into a bitmap.  This is\nnice since we try and allocate out of the front of a block group, so if the\nfront of a block group is heavily fragmented and then has a huge chunk of free\nspace at the end, we go ahead and add the fragmented areas to bitmaps and use a\nnormal extent entry to track the big chunk at the back of the block group.\n\nI\u0027ve also taken the opportunity to revamp how we search for free space.\nPreviously we indexed free space via an offset indexed rb tree and a bytes\nindexed rb tree.  I\u0027ve dropped the bytes indexed rb tree and use only the offset\nindexed rb tree.  This cuts the number of tree operations we were doing\npreviously down by half, and gives us a little bit of a better allocation\npattern since we will always start from a specific offset and search forward\nfrom there, instead of searching for the size we need and try and get it as\nclose as possible to the offset we want.\n\nI\u0027ve given this a healthy amount of testing pre-new format stuff, as well as\npost-new format stuff.  I\u0027ve booted up my fedora box which is installed on btrfs\nwith this patch and ran with it for a few days without issues.  I\u0027ve not seen\nany performance regressions in any of my tests.\n\nSince the last patch Yan Zheng fixed a problem where we could have overlapping\nentries, so updating their offset inline would cause problems.  Thanks,\n\nSigned-off-by: Josef Bacik \u003cjbacik@redhat.com\u003e\nSigned-off-by: Chris Mason \u003cchris.mason@oracle.com\u003e\n"
    },
    {
      "commit": "451d7585a8bb1b9bec0d676ce3dece1923164e55",
      "tree": "b4e9103b7010e45e02deff9ae4470df71475f8de",
      "parents": [
        "c604480171c510c1beeb81b82418e5bc4de8f1ae"
      ],
      "author": {
        "name": "Chris Mason",
        "email": "chris.mason@oracle.com",
        "time": "Tue Jun 09 20:28:34 2009 -0400"
      },
      "committer": {
        "name": "Chris Mason",
        "email": "chris.mason@oracle.com",
        "time": "Wed Jun 10 11:29:52 2009 -0400"
      },
      "message": "Btrfs: add mount -o ssd_spread to spread allocations out\n\nSome SSDs perform best when reusing block numbers often, while\nothers perform much better when clustering strictly allocates\nbig chunks of unused space.\n\nThe default mount -o ssd will find rough groupings of blocks\nwhere there are a bunch of free blocks that might have some\nallocated blocks mixed in.\n\nmount -o ssd_spread will make sure there are no allocated blocks\nmixed in.  It should perform better on lower end SSDs.\n\nSigned-off-by: Chris Mason \u003cchris.mason@oracle.com\u003e\n"
    },
    {
      "commit": "fa9c0d795f7b57c76560b7fac703f5d341210e28",
      "tree": "74d9d9846e21ce5b99738f3cc13b855fb63d1eba",
      "parents": [
        "8e73f275011b3264a87339fd9f1690e944e381c9"
      ],
      "author": {
        "name": "Chris Mason",
        "email": "chris.mason@oracle.com",
        "time": "Fri Apr 03 09:47:43 2009 -0400"
      },
      "committer": {
        "name": "Chris Mason",
        "email": "chris.mason@oracle.com",
        "time": "Fri Apr 03 09:47:43 2009 -0400"
      },
      "message": "Btrfs: rework allocation clustering\n\nBecause btrfs is copy-on-write, we end up picking new locations for\nblocks very often.  This makes it fairly difficult to maintain perfect\nread patterns over time, but we can at least do some optimizations\nfor writes.\n\nThis is done today by remembering the last place we allocated and\ntrying to find a free space hole big enough to hold more than just one\nallocation.  The end result is that we tend to write sequentially to\nthe drive.\n\nThis happens all the time for metadata and it happens for data\nwhen mounted -o ssd.  But, the way we record it is fairly racey\nand it tends to fragment the free space over time because we are trying\nto allocate fairly large areas at once.\n\nThis commit gets rid of the races by adding a free space cluster object\nwith dedicated locking to make sure that only one process at a time\nis out replacing the cluster.\n\nThe free space fragmentation is somewhat solved by allowing a cluster\nto be comprised of smaller free space extents.  This part definitely\nadds some CPU time to the cluster allocations, but it allows the allocator\nto consume the small holes left behind by cow.\n\nSigned-off-by: Chris Mason \u003cchris.mason@oracle.com\u003e\n\n"
    }
  ]
}