1. 14 7月, 2007 1 次提交
    • D
      [XFS] Prevent ENOSPC from aborting transactions that need to succeed · 84e1e99f
      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: NDavid Chinner <dgc@sgi.com>
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      84e1e99f
  2. 08 5月, 2007 2 次提交
    • L
      [XFS] Fix to prevent the notorious 'NULL files' problem after a crash. · ba87ea69
      Lachlan McIlroy 提交于
      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: NLachlan McIlroy <lachlan@sgi.com>
      Signed-off-by: NDavid Chinner <dgc@sgi.com>
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      ba87ea69
    • E
      [XFS] The last argument "lsn" of xfs_trans_commit() is always called with · 1c72bf90
      Eric Sandeen 提交于
      NULL.
      
      Patch provided by Eric Sandeen.
      
      SGI-PV: 961693
      SGI-Modid: xfs-linux-melb:xfs-kern:28199a
      Signed-off-by: NEric Sandeen <sandeen@sandeen.net>
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      1c72bf90
  3. 10 2月, 2007 2 次提交
  4. 28 9月, 2006 1 次提交
  5. 20 6月, 2006 1 次提交
  6. 09 6月, 2006 1 次提交
  7. 22 3月, 2006 1 次提交
  8. 11 1月, 2006 4 次提交
  9. 02 11月, 2005 4 次提交
  10. 05 9月, 2005 1 次提交
  11. 02 9月, 2005 1 次提交
  12. 21 6月, 2005 1 次提交
  13. 06 5月, 2005 3 次提交
  14. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4