1. 13 10月, 2007 1 次提交
  2. 25 9月, 2006 2 次提交
    • M
      ocfs2: Remove i_generation from inode lock names · 24c19ef4
      Mark Fasheh 提交于
      OCFS2 puts inode meta data in the "lock value block" provided by the DLM.
      Typically, i_generation is encoded in the lock name so that a deleted inode
      on and a new one in the same block don't share the same lvb.
      
      Unfortunately, that scheme means that the read in ocfs2_read_locked_inode()
      is potentially thrown away as soon as the meta data lock is taken - we
      cannot encode the lock name without first knowing i_generation, which
      requires a disk read.
      
      This patch encodes i_generation in the inode meta data lvb, and removes the
      value from the inode meta data lock name. This way, the read can be covered
      by a lock, and at the same time we can distinguish between an up to date and
      a stale LVB.
      
      This will help cold-cache stat(2) performance in particular.
      
      Since this patch changes the protocol version, we take the opportunity to do
      a minor re-organization of two of the LVB fields.
      Signed-off-by: NMark Fasheh <mark.fasheh@oracle.com>
      24c19ef4
    • M
      ocfs2: Add dentry tracking API · 80c05846
      Mark Fasheh 提交于
      Replace the dentry vote mechanism with a cluster lock which covers a set
      of dentries. This allows us to force d_delete() only on nodes which actually
      care about an unlink.
      
      Every node that does a ->lookup() gets a read only lock on the dentry, until
      an unlink during which the unlinking node, will request an exclusive lock,
      forcing the other nodes who care about that dentry to d_delete() it. The
      effect is that we retain a very lightweight ->d_revalidate(), and at the
      same time get to make large improvements to the average case performance of
      the ocfs2 unlink and rename operations.
      
      This patch adds the higher level API and the dentry manipulation code.
      Signed-off-by: NMark Fasheh <mark.fasheh@oracle.com>
      80c05846
  3. 04 2月, 2006 1 次提交
  4. 04 1月, 2006 1 次提交