1. 31 10月, 2011 2 次提交
  2. 25 10月, 2011 1 次提交
  3. 21 10月, 2011 1 次提交
  4. 20 10月, 2011 4 次提交
  5. 19 10月, 2011 17 次提交
  6. 12 10月, 2011 3 次提交
  7. 11 10月, 2011 2 次提交
    • C
      Btrfs: make sure not to defrag extents past i_size · f7f43cc8
      Chris Mason 提交于
      The btrfs file defrag code will loop through the extents and
      force COW on them.  But there is a concurrent truncate in the middle of
      the defrag, it might end up defragging the same range over and over
      again.
      
      The problem is that writepage won't go through and do anything on pages
      past i_size, so the cow won't happen, so the file will appear to still
      be fragmented.  defrag will end up hitting the same extents again and
      again.
      
      In the worst case, the truncate can actually live lock with the defrag
      because the defrag keeps creating new ordered extents which the truncate
      code keeps waiting on.
      
      The fix here is to make defrag check for i_size inside the main loop,
      instead of just once before the looping starts.
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      f7f43cc8
    • L
      Btrfs: fix recursive auto-defrag · 2a0f7f57
      Li Zefan 提交于
      Follow those steps:
      
        # mount -o autodefrag /dev/sda7 /mnt
        # dd if=/dev/urandom of=/mnt/tmp bs=200K count=1
        # sync
        # dd if=/dev/urandom of=/mnt/tmp bs=8K count=1 conv=notrunc
      
      and then it'll go into a loop: writeback -> defrag -> writeback ...
      
      It's because writeback writes [8K, 200K] and then writes [0, 8K].
      
      I tried to make writeback know if the pages are dirtied by defrag,
      but the patch was a bit intrusive. Here I simply set writeback_index
      when we defrag a file.
      Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      2a0f7f57
  8. 08 10月, 2011 1 次提交
  9. 01 10月, 2011 1 次提交
    • J
      Btrfs: force a page fault if we have a shorty copy on a page boundary · b6316429
      Josef Bacik 提交于
      A user reported a problem where ceph was getting into 100% cpu usage while doing
      some writing.  It turns out it's because we were doing a short write on a not
      uptodate page, which means we'd fall back at one page at a time and fault the
      page in.  The problem is our position is on the page boundary, so our fault in
      logic wasn't actually reading the page, so we'd just spin forever or until the
      page got read in by somebody else.  This will force a readpage if we end up
      doing a short copy.  Alexandre could reproduce this easily with ceph and reports
      it fixes his problem.  I also wrote a reproducer that no longer hangs my box
      with this patch.  Thanks,
      Reported-and-tested-by: NAlexandre Oliva <aoliva@redhat.com>
      Signed-off-by: NJosef Bacik <josef@redhat.com>
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      b6316429
  10. 27 9月, 2011 3 次提交
    • L
      vfs: remove LOOKUP_NO_AUTOMOUNT flag · b6c8069d
      Linus Torvalds 提交于
      That flag no longer makes sense, since we don't look up automount points
      as eagerly any more.  Additionally, it turns out that the NO_AUTOMOUNT
      handling was buggy to begin with: it would avoid automounting even for
      cases where we really *needed* to do the automount handling, and could
      return ENOENT for autofs entries that hadn't been instantiated yet.
      
      With our new non-eager automount semantics, one discussion has been
      about adding a AT_AUTOMOUNT flag to vfs_fstatat (and thus the
      newfstatat() and fstatat64() system calls), but it's probably not worth
      it: you can always force at least directory automounting by simply
      adding the final '/' to the filename, which works for *all* of the stat
      family system calls, old and new.
      
      So AT_NO_AUTOMOUNT (and thus LOOKUP_NO_AUTOMOUNT) really were just a
      result of our bad default behavior.
      Acked-by: NIan Kent <raven@themaw.net>
      Acked-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b6c8069d
    • T
      VFS: Fix the remaining automounter semantics regressions · 815d405c
      Trond Myklebust 提交于
      The concensus seems to be that system calls such as stat() etc should
      not trigger an automount.  Neither should the l* versions.
      
      This patch therefore adds a LOOKUP_AUTOMOUNT flag to tag those lookups
      that _should_ trigger an automount on the last path element.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      [ Edited to leave out the cases that are already covered by LOOKUP_OPEN,
        LOOKUP_DIRECTORY and LOOKUP_CREATE - all of which also fundamentally
        force automounting for their own reasons   - Linus ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      815d405c
    • L
      vfs pathname lookup: Add LOOKUP_AUTOMOUNT flag · d94c177b
      Linus Torvalds 提交于
      Since we've now turned around and made LOOKUP_FOLLOW *not* force an
      automount, we want to add the ability to force an automount event on
      lookup even if we don't happen to have one of the other flags that force
      it implicitly (LOOKUP_OPEN, LOOKUP_DIRECTORY, LOOKUP_PARENT..)
      
      Most cases will never want to use this, since you'd normally want to
      delay automounting as long as possible, which usually implies
      LOOKUP_OPEN (when we open a file or directory, we really cannot avoid
      the automount any more).
      
      But Trond argued sufficiently forcefully that at a minimum bind mounting
      a file and quotactl will want to force the automount lookup.  Some other
      cases (like nfs_follow_remote_path()) could use it too, although
      LOOKUP_DIRECTORY would work there as well.
      
      This commit just adds the flag and logic, no users yet, though.  It also
      doesn't actually touch the LOOKUP_NO_AUTOMOUNT flag that is related, and
      was made irrelevant by the same change that made us not follow on
      LOOKUP_FOLLOW.
      
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Ian Kent <raven@themaw.net>
      Cc: Jeff Layton <jlayton@redhat.com>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Greg KH <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d94c177b
  11. 22 9月, 2011 3 次提交
  12. 21 9月, 2011 1 次提交
  13. 20 9月, 2011 1 次提交
    • S
      cifs: Fix broken sec=ntlmv2/i sec option (try #2) · cfbd6f84
      Shirish Pargaonkar 提交于
      Fix sec=ntlmv2/i authentication option during mount of Samba shares.
      
      cifs client was coding ntlmv2 response incorrectly.
      All that is needed in temp as specified in MS-NLMP seciton 3.3.2
      
      "Define ComputeResponse(NegFlg, ResponseKeyNT, ResponseKeyLM,
      CHALLENGE_MESSAGE.ServerChallenge, ClientChallenge, Time, ServerName)
      
      as
      Set temp to ConcatenationOf(Responserversion, HiResponserversion,
      Z(6), Time, ClientChallenge, Z(4), ServerName, Z(4)"
      
      is MsvAvNbDomainName.
      
      For sec=ntlmsspi, build_av_pair is not used, a blob is plucked from
      type 2 response sent by the server to use in authentication.
      
      I tested sec=ntlmv2/i and sec=ntlmssp/i mount options against
      Samba (3.6) and Windows - XP, 2003 Server and 7.
      They all worked.
      Signed-off-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      cfbd6f84