1. 03 10月, 2011 1 次提交
  2. 07 8月, 2011 1 次提交
    • B
      exofs: Rename raid engine from exofs/ios.c => ore · 8ff660ab
      Boaz Harrosh 提交于
      ORE stands for "Objects Raid Engine"
      
      This patch is a mechanical rename of everything that was in ios.c
      and its API declaration to an ore.c and an osd_ore.h header. The ore
      engine will later be used by the pnfs objects layout driver.
      
      * File ios.c => ore.c
      
      * Declaration of types and API are moved from exofs.h to a new
        osd_ore.h
      
      * All used types are prefixed by ore_ from their exofs_ name.
      
      * Shift includes from exofs.h to osd_ore.h so osd_ore.h is
        independent, include it from exofs.h.
      
      Other than a pure rename there are no other changes. Next patch
      will move the ore into it's own module and will export the API
      to be used by exofs and later the layout driver
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      8ff660ab
  3. 28 7月, 2011 1 次提交
  4. 27 7月, 2011 1 次提交
  5. 25 7月, 2011 3 次提交
  6. 21 7月, 2011 1 次提交
    • P
      treewide: fix potentially dangerous trailing ';' in #defined values/expressions · 497888cf
      Phil Carmody 提交于
      All these are instances of
        #define NAME value;
      or
        #define NAME(params_opt) value;
      
      These of course fail to build when used in contexts like
        if(foo $OP NAME)
        while(bar $OP NAME)
      and may silently generate the wrong code in contexts such as
        foo = NAME + 1;    /* foo = value; + 1; */
        bar = NAME - 1;    /* bar = value; - 1; */
        baz = NAME & quux; /* baz = value; & quux; */
      
      Reported on comp.lang.c,
      Message-ID: <ab0d55fe-25e5-482b-811e-c475aa6065c3@c29g2000yqd.googlegroups.com>
      Initial analysis of the dangers provided by Keith Thompson in that thread.
      
      There are many more instances of more complicated macros having unnecessary
      trailing semicolons, but this pile seems to be all of the cases of simple
      values suffering from the problem. (Thus things that are likely to be found
      in one of the contexts above, more complicated ones aren't.)
      Signed-off-by: NPhil Carmody <ext-phil.2.carmody@nokia.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      497888cf
  7. 30 6月, 2011 2 次提交
  8. 24 6月, 2011 1 次提交
  9. 27 5月, 2011 2 次提交
  10. 25 5月, 2011 1 次提交
  11. 17 5月, 2011 1 次提交
    • J
      scsi: remove performance regression due to async queue run · 9937a5e2
      Jens Axboe 提交于
      Commit c21e6beb removed our queue request_fn re-enter
      protection, and defaulted to always running the queues from
      kblockd to be safe. This was a known potential slow down,
      but should be safe.
      
      Unfortunately this is causing big performance regressions for
      some, so we need to improve this logic. Looking into the details
      of the re-enter, the real issue is on requeue of requests.
      
      Requeue of requests upon seeing a BUSY condition from the device
      ends up re-running the queue, causing traces like this:
      
      scsi_request_fn()
              scsi_dispatch_cmd()
                      scsi_queue_insert()
                              __scsi_queue_insert()
                                      scsi_run_queue()
      					scsi_request_fn()
      						...
      
      potentially causing the issue we want to avoid. So special
      case the requeue re-run of the queue, but improve it to offload
      the entire run of local queue and starved queue from a single
      workqueue callback. This is a lot better than potentially
      kicking off a workqueue run for each device seen.
      
      This also fixes the issue of the local device going into recursion,
      since the above mentioned commit never moved that queue run out
      of line.
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      9937a5e2
  12. 31 3月, 2011 1 次提交
  13. 24 3月, 2011 2 次提交
  14. 02 3月, 2011 1 次提交
    • J
      libsas: convert to libata new error handler · 00dd4998
      James Bottomley 提交于
      The conversion is quite complex given that the libata new error
      handler has to be hooked into the current libsas timeout and error
      handling.  The way this is done is to process all the failed commands
      via libsas first, but if they have no underlying sas task (and they're
      on a sata device) assume they are destined for the libata error
      handler and send them accordingly.
      
      Finally, activate the port recovery of the libata error handler for
      each port known to the host.  This is somewhat suboptimal, since that
      port may not need recovering, but given the current architecture of
      the libata error handler, it's the only way; and the spurious
      activation is harmless.
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      00dd4998
  15. 01 3月, 2011 2 次提交
  16. 26 2月, 2011 1 次提交
  17. 25 2月, 2011 5 次提交
  18. 14 2月, 2011 1 次提交
    • J
      [SCSI] libsas: convert to libata new error handler · c299190b
      James Bottomley 提交于
      The conversion is quite complex given that the libata new error
      handler has to be hooked into the current libsas timeout and error
      handling.  The way this is done is to process all the failed commands
      via libsas first, but if they have no underlying sas task (and they're
      on a sata device) assume they are destined for the libata error
      handler and send them accordingly.
      
      Finally, activate the port recovery of the libata error handler for
      each port known to the host.  This is somewhat suboptimal, since that
      port may not need recovering, but given the current architecture of
      the libata error handler, it's the only way; and the spurious
      activation is harmless.
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      c299190b
  19. 13 2月, 2011 9 次提交
  20. 25 1月, 2011 2 次提交
  21. 31 12月, 2010 1 次提交