14 Jul, 2007

2 commits

  • SGI-PV: 966004
    SGI-Modid: xfs-linux-melb:xfs-kern:28866a

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

    David Chinner
     
  • During delayed allocation extent conversion or unwritten extent
    conversion, we need to reserve some blocks for transactions reservations.
    We need to reserve these blocks in case a btree split occurs and we need
    to allocate some blocks.

    Unfortunately, we've only ever reserved the number of data blocks we are
    allocating, so in both the unwritten and delalloc case we can get ENOSPC
    to the transaction reservation. This is bad because in both cases we
    cannot report the failure to the writing application.

    The fix is two-fold:

    1 - leverage the reserved block infrastructure XFS already
    has to reserve a small pool of blocks by default to allow
    specially marked transactions to dip into when we are at
    ENOSPC.
    Default setting is min(5%, 1024 blocks).

    2 - convert critical transaction reservations to be allowed
    to dip into this pool. Spots changed are delalloc
    conversion, unwritten extent conversion and growing a
    filesystem at ENOSPC.
    This also allows growing the filesytsem to succeed at ENOSPC.

    SGI-PV: 964468
    SGI-Modid: xfs-linux-melb:xfs-kern:28865a

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

    David Chinner
     

08 May, 2007

2 commits

  • The problem that has been addressed is that of synchronising updates of
    the file size with writes that extend a file. Without the fix the update
    of a file's size, as a result of a write beyond eof, is independent of
    when the cached data is flushed to disk. Often the file size update would
    be written to the filesystem log before the data is flushed to disk. When
    a system crashes between these two events and the filesystem log is
    replayed on mount the file's size will be set but since the contents never
    made it to disk the file is full of holes. If some of the cached data was
    flushed to disk then it may just be a section of the file at the end that
    has holes.

    There are existing fixes to help alleviate this problem, particularly in
    the case where a file has been truncated, that force cached data to be
    flushed to disk when the file is closed. If the system crashes while the
    file(s) are still open then this flushing will never occur.

    The fix that we have implemented is to introduce a second file size,
    called the in-memory file size, that represents the current file size as
    viewed by the user. The existing file size, called the on-disk file size,
    is the one that get's written to the filesystem log and we only update it
    when it is safe to do so. When we write to a file beyond eof we only
    update the in- memory file size in the write operation. Later when the I/O
    operation, that flushes the cached data to disk completes, an I/O
    completion routine will update the on-disk file size. The on-disk file
    size will be updated to the maximum offset of the I/O or to the value of
    the in-memory file size if the I/O includes eof.

    SGI-PV: 958522
    SGI-Modid: xfs-linux-melb:xfs-kern:28322a

    Signed-off-by: Lachlan McIlroy
    Signed-off-by: David Chinner
    Signed-off-by: Tim Shimmin

    Lachlan McIlroy
     
  • NULL.

    Patch provided by Eric Sandeen.

    SGI-PV: 961693
    SGI-Modid: xfs-linux-melb:xfs-kern:28199a

    Signed-off-by: Eric Sandeen
    Signed-off-by: Lachlan McIlroy
    Signed-off-by: Tim Shimmin

    Eric Sandeen
     

10 Feb, 2007

2 commits

  • xfs_mac.h and xfs_cap.h provide definitions and macros that aren't used
    anywhere in XFS at all. They are left-overs from "to be implement at some
    point in the future" functionality that Irix XFS has. If this
    functionality ever goes into Linux, it will be provided at a different
    layer, most likely through the security hooks in the kernel so we will
    never need this functionality in XFS.

    Patch provided by Eric Sandeen (sandeen@sandeen.net).

    SGI-PV: 960895
    SGI-Modid: xfs-linux-melb:xfs-kern:28036a

    Signed-off-by: Eric Sandeen
    Signed-off-by: David Chinner
    Signed-off-by: Tim Shimmin

    Eric Sandeen
     
  • The firstblock argument to xfs_bmap_finish is not used by that function.
    Remove it and cleanup the code a bit.

    Patch provided by Eric Sandeen.

    SGI-PV: 960196
    SGI-Modid: xfs-linux-melb:xfs-kern:28034a

    Signed-off-by: Eric Sandeen
    Signed-off-by: David Chinner
    Signed-off-by: Tim Shimmin

    Eric Sandeen
     

28 Sep, 2006

1 commit


20 Jun, 2006

1 commit


09 Jun, 2006

1 commit

  • the range spanned by modifications to the in-core extent map. Add
    XFS_BUNMAPI() and XFS_SWAP_EXTENTS() macros that call xfs_bunmapi() and
    xfs_swap_extents() via the ioops vector. Change all calls that may modify
    the in-core extent map for the data fork to go through the ioops vector.
    This allows a cache of extent map data to be kept in sync.

    SGI-PV: 947615
    SGI-Modid: xfs-linux-melb:xfs-kern:209226a

    Signed-off-by: Olaf Weber
    Signed-off-by: Nathan Scott

    Olaf Weber
     

22 Mar, 2006

1 commit


12 Jan, 2006

1 commit


11 Jan, 2006

4 commits


02 Nov, 2005

4 commits


05 Sep, 2005

1 commit


02 Sep, 2005

1 commit


21 Jun, 2005

1 commit


06 May, 2005

3 commits


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