1. 17 10月, 2007 1 次提交
    • A
      writeback: fix time-ordering of the per-superblock dirty-inode lists · 6610a0bc
      Andrew Morton 提交于
      When writeback has finished writing back an inode it looks to see if that
      inode is still dirty.  If it is, that means that a process redirtied the inode
      while its writeback was in progress.
      
      What we need to do here is to refile the redirtied inode onto the s_dirty
      list.
      
      But we're doing that wrongly: it could be that this inode was redirtied
      _before_ the last inode on s_dirty.  We're blindly appending this inode to the
      list, after an inode which might be less-recently-dirtied, thus violating the
      list's ordering.
      
      So we must either insertion-sort this inode into the correct place, or we must
      update this inode's dirtied_when field when appending it to the reverse-sorted
      s_dirty list, to preserve the reverse-time-ordering.
      
      This patch does the latter: if this inode was dirtied less recently than the
      tail inode then copy the tail inode's timestamp into this inode.
      
      This means that in rare circumstances, some inodes will be writen back later
      than they should have been.  But the time slip will be small.
      
      Cc: Mike Waychison <mikew@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6610a0bc
  2. 10 10月, 2007 1 次提交
  3. 27 1月, 2007 1 次提交
    • L
      Write back inode data pages even when the inode itself is locked · 4b89eed9
      Linus Torvalds 提交于
      In __writeback_single_inode(), when we find a locked inode and we're not
      doing a data-integrity sync, we used to just skip writing entirely,
      since we didn't want to wait for the inode to unlock.
      
      However, there's really no reason to skip writing the data pages, which
      are likely to be the the bulk of the dirty state anyway (and the main
      reason why writeback was started for the non-data-integrity case, of
      course!)
      Acked-by: NNick Piggin <nickpiggin@yahoo.com.au>
      Cc: Andrew Morton <akpm@osdl.org>,
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: David Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4b89eed9
  4. 01 10月, 2006 2 次提交
  5. 01 7月, 2006 2 次提交
  6. 23 6月, 2006 2 次提交
    • J
      [PATCH] Kill PF_SYNCWRITE flag · b31dc66a
      Jens Axboe 提交于
      A process flag to indicate whether we are doing sync io is incredibly
      ugly. It also causes performance problems when one does a lot of async
      io and then proceeds to sync it. Part of the io will go out as async,
      and the other part as sync. This causes a disconnect between the
      previously submitted io and the synced io. For io schedulers such as CFQ,
      this will cause us lost merges and suboptimal behaviour in scheduling.
      
      Remove PF_SYNCWRITE completely from the fsync/msync paths, and let
      the O_DIRECT path just directly indicate that the writes are sync
      by using WRITE_SYNC instead.
      Signed-off-by: NJens Axboe <axboe@suse.de>
      b31dc66a
    • O
      [PATCH] writeback: fix range handling · 111ebb6e
      OGAWA Hirofumi 提交于
      When a writeback_control's `start' and `end' fields are used to
      indicate a one-byte-range starting at file offset zero, the required
      values of .start=0,.end=0 mean that the ->writepages() implementation
      has no way of telling that it is being asked to perform a range
      request.  Because we're currently overloading (start == 0 && end == 0)
      to mean "this is not a write-a-range request".
      
      To make all this sane, the patch changes range of writeback_control.
      
      So caller does: If it is calling ->writepages() to write pages, it
      sets range (range_start/end or range_cyclic) always.
      
      And if range_cyclic is true, ->writepages() thinks the range is
      cyclic, otherwise it just uses range_start and range_end.
      
      This patch does,
      
          - Add LLONG_MAX, LLONG_MIN, ULLONG_MAX to include/linux/kernel.h
            -1 is usually ok for range_end (type is long long). But, if someone did,
      
      		range_end += val;		range_end is "val - 1"
      		u64val = range_end >> bits;	u64val is "~(0ULL)"
      
            or something, they are wrong. So, this adds LLONG_MAX to avoid nasty
            things, and uses LLONG_MAX for range_end.
      
          - All callers of ->writepages() sets range_start/end or range_cyclic.
      
          - Fix updates of ->writeback_index. It seems already bit strange.
            If it starts at 0 and ended by check of nr_to_write, this last
            index may reduce chance to scan end of file.  So, this updates
            ->writeback_index only if range_cyclic is true or whole-file is
            scanned.
      Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Nathan Scott <nathans@sgi.com>
      Cc: Anton Altaparmakov <aia21@cantab.net>
      Cc: Steven French <sfrench@us.ibm.com>
      Cc: "Vladimir V. Saveliev" <vs@namesys.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      111ebb6e
  7. 26 3月, 2006 1 次提交
  8. 07 11月, 2005 2 次提交
  9. 01 11月, 2005 1 次提交
    • A
      [PATCH] fix __writeback_single_inode WARN_ON · 659603ef
      Andrea Arcangeli 提交于
      When the inode count is zero in inode writeback, the
      
      	WARN_ON(!(inode->i_state & I_WILL_FREE));
      
      is broken, and needs to test for either I_WILL_FREE|I_FREEING.
      
      When the inode is in I_FREEING state, it's already out of the visibility
      of the vm so it can't be freed so it doesn't require the __iget and the
      generic_delete_inode path can call the sync internally to the lowlevel
      fs callback during the last iput. So the inode being in I_FREEING is
      also a valid condition for calling the sync with i_count == 0.
      
      The specific stack trace is this:
      
        0xc00000007b8fb6e0  0xc00000000010118c  .__writeback_single_inode +0x5c
        0xc00000007b8fb6e0  0xc0000000001014dc (lr) .sync_inode +0x3c
        0xc00000007b8fb790  0xc0000000001014dc  .sync_inode +0x3c
        0xc00000007b8fb820  0xc0000000001a5020  .ext2_sync_inode +0x64
        0xc00000007b8fb8f0  0xc0000000001a65b4  .ext2_truncate +0x3f8
        0xc00000007b8fba40  0xc0000000001a6940  .ext2_delete_inode +0xdc
        0xc00000007b8fbac0  0xc0000000000f7a5c  .generic_delete_inode +0x124
        0xc00000007b8fbb50  0xc0000000000f5fe0  .iput +0xb8
        0xc00000007b8fbbe0  0xc0000000000e9fd4  .sys_unlink +0x2a8
        0xc00000007b8fbd10  0xc00000000001048c  .ret_from_syscall_1 +0x0
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      659603ef
  10. 31 10月, 2005 1 次提交
    • A
      [PATCH] fix nr_unused accounting, and avoid recursing in iput with I_WILL_FREE set · 7f04c26d
      Andrea Arcangeli 提交于
       			list_move(&inode->i_list, &inode_in_use);
       		} else {
       			list_move(&inode->i_list, &inode_unused);
      +			inodes_stat.nr_unused++;
       		}
       	}
       	wake_up_inode(inode);
      
      Are you sure the above diff is correct? It was added somewhere between
      2.6.5 and 2.6.8. I think it's wrong.
      
      The only way I can imagine the i_count to be zero in the above path, is
      that I_WILL_FREE is set.  And if I_WILL_FREE is set, then we must not
      increase nr_unused.  So I believe the above change is buggy and it will
      definitely overstate the number of unused inodes and it should be backed
      out.
      
      Note that __writeback_single_inode before calling __sync_single_inode, can
      drop the spinlock and we can have both the dirty and locked bitflags clear
      here:
      
      		spin_unlock(&inode_lock);
      		__wait_on_inode(inode);
      		iput(inode);
      XXXXXXX
      		spin_lock(&inode_lock);
      	}
      	use inode again here
      
      a construct like the above makes zero sense from a reference counting
      standpoint.
      
      Either we don't ever use the inode again after the iput, or the
      inode_lock should be taken _before_ executing the iput (i.e. a __iput
      would be required). Taking the inode_lock after iput means the iget was
      useless if we keep using the inode after the iput.
      
      So the only chance the 2.6 was safe to call __writeback_single_inode
      with the i_count == 0, is that I_WILL_FREE is set (I_WILL_FREE will
      prevent the VM to free the inode in XXXXX).
      
      Potentially calling the above iput with I_WILL_FREE was also wrong
      because it would recurse in iput_final (the second mainline bug).
      
      The below (untested) patch fixes the nr_unused accounting, avoids recursing
      in iput when I_WILL_FREE is set and makes sure (with the BUG_ON) that we
      don't corrupt memory and that all holders that don't set I_WILL_FREE, keeps
      a reference on the inode!
      Signed-off-by: NAndrea Arcangeli <andrea@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7f04c26d
  11. 24 6月, 2005 1 次提交
  12. 01 5月, 2005 1 次提交
  13. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4