1. 05 7月, 2008 5 次提交
  2. 03 7月, 2008 1 次提交
    • E
      9p: fix O_APPEND in legacy mode · 2e4bef41
      Eric Van Hensbergen 提交于
      The legacy protocol's open operation doesn't handle an append operation
      (it is expected that the client take care of it).  We were incorrectly
      passing the extended protocol's flag through even in legacy mode.  This
      was reported in bugzilla report #10689.  This patch fixes the problem
      by disallowing extended protocol open modes from being passed in legacy
      mode and implemented append functionality on the client side by adding
      a seek after the open.
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      2e4bef41
  3. 01 7月, 2008 1 次提交
    • J
      Properly notify block layer of sync writes · 18ce3751
      Jens Axboe 提交于
      fsync_buffers_list() and sync_dirty_buffer() both issue async writes and
      then immediately wait on them. Conceptually, that makes them sync writes
      and we should treat them as such so that the IO schedulers can handle
      them appropriately.
      
      This patch fixes a write starvation issue that Lin Ming reported, where
      xx is stuck for more than 2 minutes because of a large number of
      synchronous IO in the system:
      
      INFO: task kjournald:20558 blocked for more than 120 seconds.
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
      message.
      kjournald     D ffff810010820978  6712 20558      2
      ffff81022ddb1d10 0000000000000046 ffff81022e7baa10 ffffffff803ba6f2
      ffff81022ecd0000 ffff8101e6dc9160 ffff81022ecd0348 000000008048b6cb
      0000000000000086 ffff81022c4e8d30 0000000000000000 ffffffff80247537
      Call Trace:
      [<ffffffff803ba6f2>] kobject_get+0x12/0x17
      [<ffffffff80247537>] getnstimeofday+0x2f/0x83
      [<ffffffff8029c1ac>] sync_buffer+0x0/0x3f
      [<ffffffff8066d195>] io_schedule+0x5d/0x9f
      [<ffffffff8029c1e7>] sync_buffer+0x3b/0x3f
      [<ffffffff8066d3f0>] __wait_on_bit+0x40/0x6f
      [<ffffffff8029c1ac>] sync_buffer+0x0/0x3f
      [<ffffffff8066d48b>] out_of_line_wait_on_bit+0x6c/0x78
      [<ffffffff80243909>] wake_bit_function+0x0/0x23
      [<ffffffff8029e3ad>] sync_dirty_buffer+0x98/0xcb
      [<ffffffff8030056b>] journal_commit_transaction+0x97d/0xcb6
      [<ffffffff8023a676>] lock_timer_base+0x26/0x4b
      [<ffffffff8030300a>] kjournald+0xc1/0x1fb
      [<ffffffff802438db>] autoremove_wake_function+0x0/0x2e
      [<ffffffff80302f49>] kjournald+0x0/0x1fb
      [<ffffffff802437bb>] kthread+0x47/0x74
      [<ffffffff8022de51>] schedule_tail+0x28/0x5d
      [<ffffffff8020cac8>] child_rip+0xa/0x12
      [<ffffffff80243774>] kthread+0x0/0x74
      [<ffffffff8020cabe>] child_rip+0x0/0x12
      
      Lin Ming confirms that this patch fixes the issue. I've run tests with
      it for the past week and no ill effects have been observed, so I'm
      proposing it for inclusion into 2.6.26.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      18ce3751
  4. 25 6月, 2008 1 次提交
    • B
      [GFS2] fix gfs2 block allocation (cleaned up) · 5af4e7a0
      Benjamin Marzinski 提交于
      This patch fixes bz 450641.
      
      This patch changes the computation for zero_metapath_length(), which it
      renames to metapath_branch_start(). When you are extending the metadata
      tree, The indirect blocks that point to the new data block must either
      diverge from the existing tree either at the inode, or at the first
      indirect block. They can diverge at the first indirect block because the
      inode has room for 483 pointers while the indirect blocks have room for
      509 pointers, so when the tree is grown, there is some free space in the
      first indirect block. What metapath_branch_start() now computes is the
      height where the first indirect block for the new data block is located.
      It can either be 1 (if the indirect block diverges from the inode) or 2
      (if it diverges from the first indirect block).
      Signed-off-by: NBenjamin Marzinski <bmarzins@redhat.com>
      Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      5af4e7a0
  5. 24 6月, 2008 8 次提交
  6. 23 6月, 2008 10 次提交
  7. 20 6月, 2008 1 次提交
  8. 18 6月, 2008 1 次提交
  9. 17 6月, 2008 5 次提交
  10. 16 6月, 2008 1 次提交
  11. 13 6月, 2008 3 次提交
  12. 11 6月, 2008 2 次提交
  13. 07 6月, 2008 1 次提交