1. 06 6月, 2012 1 次提交
    • B
      GFS2: Extend the life of the reservations · 0a305e49
      Bob Peterson 提交于
      This patch lengthens the lifespan of the reservations structure for
      inodes. Before, they were allocated and deallocated for every write
      operation. With this patch, they are allocated when the first write
      occurs, and deallocated when the last process closes the file.
      It's more efficient to do it this way because it saves GFS2 a lot of
      unnecessary allocates and frees. It also gives us more flexibility
      for the future: (1) we can now fold the qadata structure back into
      the structure and save those alloc/frees, (2) we can use this for
      multi-block reservations.
      Signed-off-by: NBob Peterson <rpeterso@redhat.com>
      Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
      0a305e49
  2. 05 6月, 2012 1 次提交
    • L
      vfs: Fix /proc/<tid>/fdinfo/<fd> file handling · 0640113b
      Linus Torvalds 提交于
      Cyrill Gorcunov reports that I broke the fdinfo files with commit
      30a08bf2 ("proc: move fd symlink i_mode calculations into
      tid_fd_revalidate()"), and he's quite right.
      
      The tid_fd_revalidate() function is not just used for the <tid>/fd
      symlinks, it's also used for the <tid>/fdinfo/<fd> files, and the
      permission model for those are different.
      
      So do the dynamic symlink permission handling just for symlinks, making
      the fdinfo files once more appear as the proper regular files they are.
      
      Of course, Al Viro argued (probably correctly) that we shouldn't do the
      symlink permission games at all, and make the symlinks always just be
      the normal 'lrwxrwxrwx'.  That would have avoided this issue too, but
      since somebody noticed that the permissions had changed (which was the
      reason for that original commit 30a08bf2 in the first place), people
      do apparently use this feature.
      
      [ Basically, you can use the symlink permission data as a cheap "fdinfo"
        replacement, since you see whether the file is open for reading and/or
        writing by just looking at st_mode of the symlink.  So the feature
        does make sense, even if the pain it has caused means we probably
        shouldn't have done it to begin with. ]
      Reported-and-tested-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0640113b
  3. 02 6月, 2012 25 次提交
  4. 01 6月, 2012 13 次提交