13 Jul, 2011

1 commit

  • Replace the current mess of dir2 headers with just three that have a clear
    purpose:

    - xfs_dir2_format.h for all format definitions, including the inline helpers
    to access our variable size structures
    - xfs_dir2_priv.h for all prototypes that are internal to the dir2 code
    and not needed by anything outside of the directory code. For this
    purpose xfs_da_btree.c, and phase6.c in xfs_repair are considered part
    of the directory code.
    - xfs_dir2.h for the public interface to the directory code

    In addition to the reshuffle I have also update the comments to not only
    match the new file structure, but also to describe the directory format
    better.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Alex Elder
    Reviewed-by: Dave Chinner

    Christoph Hellwig
     

08 Jul, 2011

4 commits

  • Micro-optimize various comparisms by always byteswapping the constant
    instead of the variable, which allows to do the swap at compile instead
    of runtime.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Alex Elder
    Reviewed-by: Dave Chinner

    Christoph Hellwig
     
  • Remove the confusing xfs_dir2_data structure. It is supposed to describe
    an XFS dir2 data btree block, but due to the variable sized nature of
    almost all elements in it it can't actuall do anything close to that
    job. In addition to accessing the fixed offset header structure it was
    only used to get a pointer to the first dir or unused entry after it,
    which can be trivially replaced by pointer arithmetics on the header
    pointer. For most users that is actually more natural anyway, as they
    don't use a typed pointer but rather a character pointer for further
    arithmetics.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Alex Elder
    Reviewed-by: Dave Chinner

    Christoph Hellwig
     
  • In most places we can simply pass around and use the struct xfs_dir2_data_hdr,
    which is the first and most important member of struct xfs_dir2_data instead
    of the full structure.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Alex Elder
    Reviewed-by: Dave Chinner

    Christoph Hellwig
     
  • In most places we can simply pass around and use the struct xfs_dir2_data_hdr,
    which is the first and most important member of struct xfs_dir2_block instead
    of the full structure.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Alex Elder
    Reviewed-by: Dave Chinner

    Christoph Hellwig
     

27 Jul, 2010

2 commits

  • Signed-off-by: Christoph Hellwig
    Reviewed-by: Dave Chinner

    Christoph Hellwig
     
  • Dmapi support was never merged upstream, but we still have a lot of hooks
    bloating XFS for it, all over the fast pathes of the filesystem.

    This patch drops over 700 lines of dmapi overhead. If we'll ever get HSM
    support in mainline at least the namespace events can be done much saner
    in the VFS instead of the individual filesystem, so it's not like this
    is much help for future work.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Dave Chinner

    Christoph Hellwig
     

28 Jul, 2008

1 commit

  • Adds two pieces of functionality for the basis of case-insensitive support
    in XFS:

    1. A comparison result enumerated type: xfs_dacmp. It represents an

    exact match, case-insensitive match or no match at all. This patch

    only implements different and exact results.

    2. xfs_nameops vector for specifying how to perform the hash generation

    of filenames and comparision methods. In this patch the hash vector

    points to the existing xfs_da_hashname function and the comparison

    method does a length compare, and if the same, does a memcmp and

    return the xfs_dacmp result.

    All filename functions that use the hash (create, lookup remove, rename,
    etc) now use the xfs_nameops.hashname function and all directory lookup
    functions also use the xfs_nameops.compname function.

    The lookup functions also handle case-insensitive results even though the
    default comparison function cannot return that. And important aspect of
    the lookup functions is that an exact match always has precedence over a
    case-insensitive. So while a case-insensitive match is found, we have to
    keep looking just in case there is an exact match. In the meantime, the
    info for the first case-insensitive match is retained if no exact match is
    found.

    SGI-PV: 981519
    SGI-Modid: xfs-linux-melb:xfs-kern:31205a

    Signed-off-by: Barry Naujok
    Signed-off-by: Christoph Hellwig

    Barry Naujok
     

14 Feb, 2008

1 commit


15 Oct, 2007

1 commit

  • One of the perpetual scaling problems XFS has is indexing it's incore
    inodes. We currently uses hashes and the default hash sizes chosen can
    only ever be a tradeoff between memory consumption and the maximum
    realistic size of the cache.

    As a result, anyone who has millions of inodes cached on a filesystem
    needs to tunes the size of the cache via the ihashsize mount option to
    allow decent scalability with inode cache operations.

    A further problem is the separate inode cluster hash, whose size is based
    on the ihashsize but is smaller, and so under certain conditions (sparse
    cluster cache population) this can become a limitation long before the
    inode hash is causing issues.

    The following patchset removes the inode hash and cluster hash and
    replaces them with radix trees to avoid the scalability limitations of the
    hashes. It also reduces the size of the inodes by 3 pointers....

    SGI-PV: 969561
    SGI-Modid: xfs-linux-melb:xfs-kern:29481a

    Signed-off-by: David Chinner
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Tim Shimmin

    David Chinner
     

14 Jul, 2007

1 commit


08 May, 2007

1 commit


20 Jun, 2006

1 commit


09 Jun, 2006

1 commit


17 Mar, 2006

6 commits


02 Nov, 2005

2 commits


21 Jun, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds