07 Mar, 2011

3 commits

  • Once converted, kill the remainder of the cmn_err() interface.

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

    Dave Chinner
     
  • In certain cases of inode corruption, the xfs_fs_repair_cmn_err()
    macro is used to output an extra message in the corruption report.
    That extra message is "unmount and run xfs_repair", which really
    applies to any corruption report. Each case that this macro is
    called (except one) a following call to xfs_corruption_error() is
    made to optionally dump more information about the error.

    Hence, move the output of "run xfs_repair" to xfs_corruption_error()
    so that it is output on all corruption reports. Also, convert the
    callers of the repair macro that don't call xfs_corruption_error()
    to call it, hence provide consiѕtent error reporting for all cases
    where xfs_fs_repair_cmn_err() used to be called.

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

    Dave Chinner
     
  • Continue the conversion of the old cmn_err interface be converting
    all the conditional panic tag errors to xfs_alert_tag() and then
    removing xfs_cmn_err().

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

    Dave Chinner
     

12 Jan, 2011

1 commit

  • We currently have a global error message buffer in cmn_err that is
    protected by a spin lock that disables interrupts. Recently there
    have been reports of NMI timeouts occurring when the console is
    being flooded by SCSI error reports due to cmn_err() getting stuck
    trying to print to the console while holding this lock (i.e. with
    interrupts disabled). The NMI watchdog is seeing this CPU as
    non-responding and so is triggering a panic. While the trigger for
    the reported case is SCSI errors, pretty much anything that spams
    the kernel log could cause this to occur.

    Realistically the only reason that we have the intemediate message
    buffer is to prepend the correct kernel log level prefix to the log
    message. The only reason we have the lock is to protect the global
    message buffer and the only reason the message buffer is global is
    to keep it off the stack. Hence if we can avoid needing a global
    message buffer we avoid needing the lock, and we can do this with a
    small amount of cleanup and some preprocessor tricks:

    1. clean up xfs_cmn_err() panic mask functionality to avoid
    needing debug code in xfs_cmn_err()
    2. remove the couple of "!" message prefixes that still exist that
    the existing cmn_err() code steps over.
    3. redefine CE_* levels directly to KERN_*
    4. redefine cmn_err() and friends to use printk() directly
    via variable argument length macros.

    By doing this, we can completely remove the cmn_err() code and the
    lock that is causing the problems, and rely solely on printk()
    serialisation to ensure that we don't get garbled messages.

    A series of followup patches is really needed to clean up all the
    cmn_err() calls and related messages properly, but that results in a
    series that is not easily back portable to enterprise kernels. Hence
    this initial fix is only to address the direct problem in the lowest
    impact way possible.

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

    Dave Chinner
     

01 Dec, 2010

1 commit

  • Recent tests writing lots of small files showed the flusher thread
    being CPU bound and taking a long time to do allocations on a debug
    kernel. perf showed this as the prime reason:

    samples pcnt function DSO
    _______ _____ ___________________________ _________________

    224648.00 36.8% xfs_error_test [kernel.kallsyms]
    86045.00 14.1% xfs_btree_check_sblock [kernel.kallsyms]
    39778.00 6.5% prandom32 [kernel.kallsyms]
    37436.00 6.1% xfs_btree_increment [kernel.kallsyms]
    29278.00 4.8% xfs_btree_get_rec [kernel.kallsyms]
    27717.00 4.5% random32 [kernel.kallsyms]

    Walking btree blocks during allocation checking them requires each
    block (a cache hit, so no I/O) call xfs_error_test(), which then
    does a random32() call as the first operation. IOWs, ~50% of the
    CPU is being consumed just testing whether we need to inject an
    error, even though error injection is not active.

    Kill this overhead when error injection is not active by adding a
    global counter of active error traps and only calling into
    xfs_error_test when fault injection is active.

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

    Dave Chinner
     

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
     

24 May, 2010

1 commit

  • Push the error message output when a ticket overrun is detected
    into the ticket printing functions. Also remove the debug version
    of the code as the production version will still panic just as
    effectively on a debug kernel via the panic mask being set.

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

    Dave Chinner
     

19 May, 2010

1 commit


22 Dec, 2008

1 commit

  • xfs_fs_vcmn_err can be called under a spinlock, but does a sleeping memory
    allocation to create buffer for it's internal sprintf. Fortunately it's
    the only caller of icmn_err, so we can merge the two and have one single
    static buffer and spinlock protecting it. While we're at it make sure
    we proper __attribute__ format annotations so that the compiler can detect
    mismatched format strings.

    Reported-by: Alexander Beregalov
    Signed-off-by: Christoph Hellwig
    Reviewed-by: Eric Sandeen
    Signed-off-by: Lachlan McIlroy

    Christoph Hellwig
     

13 Aug, 2008

1 commit

  • All the error injection is already enabled through ifdef DEBUG, so kill
    the never set second cpp symbol to activate it without the rest of the
    debugging infrastructure.

    SGI-PV: 981498

    SGI-Modid: xfs-linux-melb:xfs-kern:31771a

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Niv Sardi
    Signed-off-by: Lachlan McIlroy

    Christoph Hellwig
     

28 Jul, 2008

2 commits

  • Currently the xfs module init/exit code is a mess. It's farmed out over a
    lot of function with very little error checking. This patch makes sure we
    propagate all initialization failures properly and clean up after them.
    Various runtime initializations are replaced with compile-time
    initializations where possible to make this easier. The exit path is
    similarly consolidated.

    There's now split out function to create/destroy the kmem zones and
    alloc/free the trace buffers. I've also changed the ktrace allocations to
    KM_MAYFAIL and handled errors resulting from that.

    And yes, we really should replace the XFS_*_TRACE ifdefs with a single
    XFS_TRACE..

    SGI-PV: 976035

    SGI-Modid: xfs-linux-melb:xfs-kern:31354a

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Niv Sardi
    Signed-off-by: Lachlan McIlroy

    Christoph Hellwig
     
  • kmem_free() function takes (ptr, size) arguments but doesn't actually use
    second one.

    This patch removes size argument from all callsites.

    SGI-PV: 981498
    SGI-Modid: xfs-linux-melb:xfs-kern:31050a

    Signed-off-by: Denys Vlasenko
    Signed-off-by: David Chinner
    Signed-off-by: Lachlan McIlroy

    Denys Vlasenko
     

07 Feb, 2008

1 commit


16 Oct, 2007

1 commit

  • vfs_altfsid was just a pointer to mp->m_fixedfsid so we can trivially
    replace it with the latter. vfs_fsid also was identical to m_fixedfsid
    through rather obfuscated ways so we can kill it as well and simply its
    only user.

    SGI-PV: 969608
    SGI-Modid: xfs-linux-melb:xfs-kern:29506a

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

    Christoph Hellwig
     

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
     

08 May, 2007

1 commit


10 Feb, 2007

1 commit


20 Jun, 2006

1 commit


12 Jan, 2006

1 commit


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