Doug / smarc-fsl-linux-kernel

18 Apr, 2008

1 commit

  • 7e20694d9   [XFS] Remove periodic logging of in-core superblock counters. ... Browse Code »

    xfssyncd triggers the logging of superblock counters every 30s if the
    filesystem is made with lazy-count=1. This will prevent disks from idling
    and spinning down as there will be a log write every 30s. With the way
    counter recovery works for lazy-count=1, this code is unnecessary and
    provides no real benefit, so just remove it.

    SGI-PV: 980145
    SGI-Modid: xfs-linux-melb:xfs-kern:30840a

    Signed-off-by: David Chinner
    Signed-off-by: Barry Naujok
    Signed-off-by: Lachlan McIlroy

    David Chinner
     

16 Oct, 2007

9 commits

14 Jul, 2007

2 commits

  • 516b2e7c2   [XFS] Fix remount,readonly path to flush everything correctly. ... Browse Code »

    The remount readonly path can fail to writeback properly because we still
    have active transactions after calling xfs_quiesce_fs(). Further
    investigation shows that this path is broken in the same ways that the xfs
    freeze path was broken so fix it the same way.

    SGI-PV: 964464
    SGI-Modid: xfs-linux-melb:xfs-kern:28869a

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

    David Chinner
     
  • 92821e2ba   [XFS] Lazy Superblock Counters ... Browse Code »

    When we have a couple of hundred transactions on the fly at once, they all
    typically modify the on disk superblock in some way.
    create/unclink/mkdir/rmdir modify inode counts, allocation/freeing modify
    free block counts.

    When these counts are modified in a transaction, they must eventually lock
    the superblock buffer and apply the mods. The buffer then remains locked
    until the transaction is committed into the incore log buffer. The result
    of this is that with enough transactions on the fly the incore superblock
    buffer becomes a bottleneck.

    The result of contention on the incore superblock buffer is that
    transaction rates fall - the more pressure that is put on the superblock
    buffer, the slower things go.

    The key to removing the contention is to not require the superblock fields
    in question to be locked. We do that by not marking the superblock dirty
    in the transaction. IOWs, we modify the incore superblock but do not
    modify the cached superblock buffer. In short, we do not log superblock
    modifications to critical fields in the superblock on every transaction.
    In fact we only do it just before we write the superblock to disk every
    sync period or just before unmount.

    This creates an interesting problem - if we don't log or write out the
    fields in every transaction, then how do the values get recovered after a
    crash? the answer is simple - we keep enough duplicate, logged information
    in other structures that we can reconstruct the correct count after log
    recovery has been performed.

    It is the AGF and AGI structures that contain the duplicate information;
    after recovery, we walk every AGI and AGF and sum their individual
    counters to get the correct value, and we do a transaction into the log to
    correct them. An optimisation of this is that if we have a clean unmount
    record, we know the value in the superblock is correct, so we can avoid
    the summation walk under normal conditions and so mount/recovery times do
    not change under normal operation.

    One wrinkle that was discovered during development was that the blocks
    used in the freespace btrees are never accounted for in the AGF counters.
    This was once a valid optimisation to make; when the filesystem is full,
    the free space btrees are empty and consume no space. Hence when it
    matters, the "accounting" is correct. But that means the when we do the
    AGF summations, we would not have a correct count and xfs_check would
    complain. Hence a new counter was added to track the number of blocks used
    by the free space btrees. This is an *on-disk format change*.

    As a result of this, lazy superblock counters are a mkfs option and at the
    moment on linux there is no way to convert an old filesystem. This is
    possible - xfs_db can be used to twiddle the right bits and then
    xfs_repair will do the format conversion for you. Similarly, you can
    convert backwards as well. At some point we'll add functionality to
    xfs_admin to do the bit twiddling easily....

    SGI-PV: 964999
    SGI-Modid: xfs-linux-melb:xfs-kern:28652a

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

    David Chinner
     

10 Feb, 2007

2 commits

  • 3c0dc77b4   [XFS] Make freeze code a little cleaner. ... Browse Code »

    Fixes a few small issues (mostly cosmetic) that were picked up during the
    review cycle for the last set of freeze path changes.

    SGI-PV: 959267
    SGI-Modid: xfs-linux-melb:xfs-kern:28035a

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

    David Chinner
     
  • 2823945fd   [XFS] Ensure a frozen filesystem has a clean log before writing the dummy ... Browse Code »

    record.

    The current Linux XFS freeze code is a mess. We flush the metadata buffers
    out while we are still allowing new transactions to start and then fail to
    flush the dirty buffers back out before writing the unmount and dummy
    records to the log.

    This leads to problems when the frozen filesystem is used for snapshots -
    we do log recovery on a readonly image and often it appears that the log
    image in the snapshot is not correct. Hence we end up with hangs, oops and
    mount failures when trying to mount a snapshot image that has been created
    when the filesystem has not been correctly frozen.

    To fix this, we need to move th metadata flush to after we wait for all
    current transactions to complete in teh second stage of the freeze. This
    means that when we write the final log records, the log should be clean
    and recovery should never occur on a snapshot image created from a frozen
    filesystem.

    SGI-PV: 959267
    SGI-Modid: xfs-linux-melb:xfs-kern:28010a

    Signed-off-by: David Chinner
    Signed-off-by: Donald Douwsma
    Signed-off-by: Tim Shimmin

    David Chinner
     

28 Sep, 2006

1 commit

09 Jun, 2006

5 commits

29 Mar, 2006

1 commit

17 Mar, 2006

1 commit

02 Nov, 2005

2 commits

05 Sep, 2005

1 commit

21 Jun, 2005

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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