)]}'
{
  "log": [
    {
      "commit": "831c2dc5f47c1dc79c32229d75065ada1dcc66e1",
      "tree": "8be3ce44e1377ed040e6c0ee3ea242dbbf75c46b",
      "parents": [
        "5f0a6e2d503896062f641639dacfe5055c2f593b"
      ],
      "author": {
        "name": "Boaz Harrosh",
        "email": "bharrosh@panasas.com",
        "time": "Tue Nov 29 15:35:53 2011 -0800"
      },
      "committer": {
        "name": "Boaz Harrosh",
        "email": "bharrosh@panasas.com",
        "time": "Fri Jan 06 16:48:14 2012 +0200"
      },
      "message": "ore: FIX breakage when MISC_FILESYSTEMS is not set\n\nAs Reported by Randy Dunlap\n\nWhen MISC_FILESYSTEMS is not enabled and NFS4.1 is:\n\nfs/built-in.o: In function `objio_alloc_io_state\u0027:\nobjio_osd.c:(.text+0xcb525): undefined reference to `ore_get_rw_state\u0027\nfs/built-in.o: In function `_write_done\u0027:\nobjio_osd.c:(.text+0xcb58d): undefined reference to `ore_check_io\u0027\nfs/built-in.o: In function `_read_done\u0027:\n...\n\nWhen MISC_FILESYSTEMS, which is more of a GUI thing then anything else,\nis not selected. exofs/Kconfig is never examined during Kconfig,\nand it can not do it\u0027s magic stuff to automatically select everything\nneeded.\n\nWe must split exofs/Kconfig in two. The ore one is always included.\nAnd the exofs one is left in it\u0027s old place in the menu.\n\n[Needed for the 3.2.0 Kernel]\nCC: Stable Tree \u003cstable@kernel.org\u003e\nReported-by: Randy Dunlap \u003crdunlap@xenotime.net\u003e\nSigned-off-by: Boaz Harrosh \u003cbharrosh@panasas.com\u003e\n"
    },
    {
      "commit": "eecfc6312a24e6d0d2883de0a9a6ccf8e993f472",
      "tree": "83b7b6d8895a007e698e59f065924527e8870d90",
      "parents": [
        "af4f5b54bcf0379089d01518e818f37258708fb7"
      ],
      "author": {
        "name": "Boaz Harrosh",
        "email": "bharrosh@panasas.com",
        "time": "Mon Oct 31 15:15:38 2011 -0700"
      },
      "committer": {
        "name": "Trond Myklebust",
        "email": "Trond.Myklebust@netapp.com",
        "time": "Wed Nov 02 23:56:08 2011 -0400"
      },
      "message": "pnfs-obj: move to ore 02: move to ORE\n\nIn this patch we are actually moving to the ORE.\n(Object Raid Engine).\n\nobjio_state holds a pointer to an ore_io_state. Once\nwe have an ore_io_state at hand we can call the ore\nfor reading/writing. We register on the done path\nto kick off the nfs io_done mechanism.\n\nAgain for Ease of reviewing the old code is \"#if 0\"\nbut is not removed so the diff command works better.\nThe old code will be removed in the next patch.\n\nfs/exofs/Kconfig::ORE is modified to also be auto-included\nif PNFS_OBJLAYOUT is set. Since we now depend on ORE.\n(See comments in fs/exofs/Kconfig)\n\nSigned-off-by: Boaz Harrosh \u003cbharrosh@panasas.com\u003e\nSigned-off-by: Trond Myklebust \u003cTrond.Myklebust@netapp.com\u003e\n"
    },
    {
      "commit": "769ba8d92025fa390f3097e658b8ed6e032d68e9",
      "tree": "eec1a556d6b3796f702c96e7f97ce94ba7d9d410",
      "parents": [
        "a1fec1dbbc8db974d2582e4040590cebe72171e4"
      ],
      "author": {
        "name": "Boaz Harrosh",
        "email": "bharrosh@panasas.com",
        "time": "Fri Oct 14 15:33:51 2011 +0200"
      },
      "committer": {
        "name": "Boaz Harrosh",
        "email": "bharrosh@panasas.com",
        "time": "Mon Oct 24 17:15:33 2011 -0700"
      },
      "message": "ore: RAID5 Write\n\nThis is finally the RAID5 Write support.\n\nThe bigger part of this patch is not the XOR engine itself, But the\nread4write logic, which is a complete mini prepare_for_striping\nreading engine that can read scattered pages of a stripe into cache\nso it can be used for XOR calculation. That is, if the write was not\nstripe aligned.\n\nThe main algorithm behind the XOR engine is the 2 dimensional array:\n\tstruct __stripe_pages_2d.\nA drawing might save 1000 words\n---\n\n__stripe_pages_2d\n       |\n n \u003d pages_in_stripe_unit;\n w \u003d group_width - parity;\n       |                            pages array presented to the XOR lib\n       |                                                |\n       V                                                |\n __1_page_stripe[0].pages --\u003e [c0][c1]..[cw][c_par] \u003c---|\n       |                                                |\n __1_page_stripe[1].pages --\u003e [c0][c1]..[cw][c_par] \u003c---\n       |\n...    |                         ...\n       |\n __1_page_stripe[n].pages --\u003e [c0][c1]..[cw][c_par]\n                               ^\n                               |\n           data added columns first then row\n\n---\nThe pages are put on this array columns first. .i.e:\n\tp0-of-c0, p1-of-c0, ... pn-of-c0, p0-of-c1, ...\nSo we are doing a corner turn of the pages.\n\nNote that pages will zigzag down and left. but are put sequentially\nin growing order. So when the time comes to XOR the stripe, only the\nbeginning and end of the array need be checked. We scan the array\nand any NULL spot will be field by pages-to-be-read.\n\nThe FS that wants to support RAID5 needs to supply an\noperations-vector that searches a given page in cache, and specifies\nif the page is uptodate or need reading. All these pages to be read\nare put on a slave ore_io_state and synchronously read. All the pages\nof a stripe are read in one IO, using the scatter gather mechanism.\n\nIn write we constrain our IO to only be incomplete on a single\nstripe. Meaning either the complete IO is within a single stripe so\nwe might have pages to read from both beginning  or end of the\nstrip. Or we have some reading to do at beginning but end at strip\nboundary. The left over pages are pushed to the next IO by the API\nalready established by previous work, where an IO offset/length\ncombination presented to the ORE might get the length truncated and\nthe user must re-submit the leftover pages. (Both exofs and NFS\nsupport this)\n\nBut any ORE user should make it\u0027s best effort to align it\u0027s IO\nbefore hand and avoid complications. A cached ore_layout-\u003estripe_size\nmember can be used for that calculation. (NOTE: that ORE demands\nthat stripe_size may not be bigger then 32bit)\n\nWhat else? Well read it and tell me.\n\nSigned-off-by: Boaz Harrosh \u003cbharrosh@panasas.com\u003e\n"
    },
    {
      "commit": "cf283ade08c454e884394a4720f22421dd33a715",
      "tree": "749bf95c36083fe35bdf020d71ab667283b486c4",
      "parents": [
        "8ff660ab85f524bdc7652eb5d38aaef1d66aa9c7"
      ],
      "author": {
        "name": "Boaz Harrosh",
        "email": "bharrosh@panasas.com",
        "time": "Sat Aug 06 19:22:06 2011 -0700"
      },
      "committer": {
        "name": "Boaz Harrosh",
        "email": "bharrosh@panasas.com",
        "time": "Sat Aug 06 19:36:19 2011 -0700"
      },
      "message": "ore: Make ore its own module\n\nExport everything from ore need exporting. Change Kbuild and Kconfig\nto build ore.ko as an independent module. Import ore from exofs\n\nSigned-off-by: Boaz Harrosh \u003cbharrosh@panasas.com\u003e\n"
    },
    {
      "commit": "b14f8ab2844987f013253dd04b708bde7fc1b52d",
      "tree": "52af3569943e17a29d4ed08d2df37211d8dc7ea8",
      "parents": [
        "15f7176eb1cccec0a332541285ee752b935c1c85"
      ],
      "author": {
        "name": "Boaz Harrosh",
        "email": "bharrosh@panasas.com",
        "time": "Mon Oct 27 18:27:55 2008 +0200"
      },
      "committer": {
        "name": "Boaz Harrosh",
        "email": "bharrosh@panasas.com",
        "time": "Tue Mar 31 19:44:20 2009 +0300"
      },
      "message": "exofs: Kbuild, Headers and osd utils\n\nThis patch includes osd infrastructure that will be used later by\nthe file system.\n\nAlso the declarations of constants, on disk structures,\nand prototypes.\n\nAnd the Kbuild+Kconfig files needed to build the exofs module.\n\nSigned-off-by: Boaz Harrosh \u003cbharrosh@panasas.com\u003e\n"
    }
  ]
}