1. 01 2月, 2012 16 次提交
  2. 13 1月, 2012 16 次提交
  3. 10 1月, 2012 1 次提交
    • T
      NFSv4: Change the default setting of the nfs4_disable_idmapping parameter · 074b1d12
      Trond Myklebust 提交于
      Now that the use of numeric uids/gids is officially sanctioned in
      RFC3530bis, it is time to change the default here to 'enabled'.
      
      By doing so, we ensure that NFSv4 copies the behaviour of NFSv3 when we're
      using the default AUTH_SYS authentication (i.e. when the client uses the
      numeric uids/gids as authentication tokens), so that when new files are
      created, they will appear to have the correct user/group.
      It also fixes a number of backward compatibility issues when migrating
      from NFSv3 to NFSv4 on a platform where the server uses different uid/gid
      mappings than the client.
      
      Note also that this setting has been successfully tested against servers
      that do not support numeric uids/gids at several Connectathon/Bakeathon
      events at this point, and the fall back to using string names/groups has
      been shown to work well in all those test cases.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      074b1d12
  4. 08 1月, 2012 1 次提交
    • T
      NFSv4: Save the owner/group name string when doing open · 6926afd1
      Trond Myklebust 提交于
      ...so that we can do the uid/gid mapping outside the asynchronous RPC
      context.
      This fixes a bug in the current NFSv4 atomic open code where the client
      isn't able to determine what the true uid/gid fields of the file are,
      (because the asynchronous nature of the OPEN call denies it the ability
      to do an upcall) and so fills them with default values, marking the
      inode as needing revalidation.
      Unfortunately, in some cases, the VFS will do some additional sanity
      checks on the file, and may override the server's decision to allow
      the open because it sees the wrong owner/group fields.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      6926afd1
  5. 07 1月, 2012 4 次提交
  6. 06 1月, 2012 2 次提交
    • T
      NFS: Remove pNFS bloat from the generic write path · e2fecb21
      Trond Myklebust 提交于
      We have no business doing any this in the standard write release path.
      Get rid of it, and put it in the pNFS layer.
      
      Also, while we're at it, get rid of the completely bogus unlock/relock
      semantics that were present in nfs_writeback_release_full(). It is
      not only unnecessary, but actually dangerous to release the write lock
      just in order to take it again in nfs_page_async_flush(). Better just
      to open code the pgio operations in a pnfs helper.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      e2fecb21
    • B
      pnfs-obj: Must return layout on IO error · fe0fe835
      Boaz Harrosh 提交于
      As mandated by the standard. In case of an IO error, a pNFS
      objects layout driver must return it's layout. This is because
      all device errors are reported to the server as part of the
      layout return buffer.
      
      This is implemented the same way PNFS_LAYOUTRET_ON_SETATTR
      is done, through a bit flag on the pnfs_layoutdriver_type->flags
      member. The flag is set by the layout driver that wants a
      layout_return preformed at pnfs_ld_{write,read}_done in case
      of an error.
      (Though I have not defined a wrapper like pnfs_ld_layoutret_on_setattr
       because this code is never called outside of pnfs.c and pnfs IO
       paths)
      
      Without this patch 3.[0-2] Kernels leak memory and have an annoying
      WARN_ON after every IO error utilizing the pnfs-obj driver.
      
      [This patch is for 3.2 Kernel. 3.1/0 Kernels need a different patch]
      CC: Stable Tree <stable@kernel.org>
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      fe0fe835
新手
引导
客服 返回
顶部