11 Sep, 2010

1 commit

  • Track negative dentries by recording the generation number of the parent
    directory in d_fsdata. The generation number for the parent directory is
    recorded in the inode_info, which increments every time the lock on the
    directory is dropped.

    If the generation number of the parent directory and the negative dentry
    matches, there is no need to perform the revalidate, else a revalidate
    is forced. This improves performance in situations where nodes look for
    the same non-existent file multiple times.

    Thanks Mark for explaining the DLM sequence.

    Signed-off-by: Goldwyn Rodrigues
    Signed-off-by: Joel Becker

    Goldwyn Rodrigues
     

22 Jul, 2009

1 commit

  • In commit ea455f8ab68338ba69f5d3362b342c115bea8e13, we moved the dentry lock
    put process into ocfs2_wq. This causes problems during umount because ocfs2_wq
    can drop references to inodes while they are being invalidated by
    invalidate_inodes() causing all sorts of nasty things (invalidate_inodes()
    ending in an infinite loop, "Busy inodes after umount" messages etc.).

    We fix the problem by stopping ocfs2_wq from doing any further releasing of
    inode references on the superblock being unmounted, wait until it finishes
    the current round of releasing and finally cleaning up all the references in
    dentry_lock_list from ocfs2_put_super().

    The issue was tracked down by Tao Ma .

    Signed-off-by: Jan Kara
    Signed-off-by: Joel Becker

    Jan Kara
     

28 Mar, 2009

1 commit


03 Feb, 2009

1 commit

  • Dropping of last reference to dentry lock is a complicated operation involving
    dropping of reference to inode. This can get complicated and quota code in
    particular needs to obtain some quota locks which leads to potential deadlock.
    Thus we defer dropping of inode reference to ocfs2_wq.

    Signed-off-by: Jan Kara
    Signed-off-by: Mark Fasheh

    Jan Kara
     

25 Sep, 2006

3 commits

  • We can't use LKM_LOCAL for new dentry locks because an unlink and subsequent
    re-create of a name/inode pair may result in the lock still being mastered
    somewhere in the cluster.

    Signed-off-by: Mark Fasheh

    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: Mark Fasheh

    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 cluster lock type which OCFS2 can attach to
    dentries. A small number of fs/ocfs2/dcache.c functions are stubbed
    out so that this change can compile.

    Signed-off-by: Mark Fasheh

    Mark Fasheh
     

04 Jan, 2006

1 commit