1. 28 7月, 2008 1 次提交
    • B
      [XFS] XFS: ASCII case-insensitive support · 189f4bf2
      Barry Naujok 提交于
      Implement ASCII case-insensitive support. It's primary purpose is for
      supporting existing filesystems that already use this case-insensitive
      mode migrated from IRIX. But, if you only need ASCII-only case-insensitive
      support (ie. English only) and will never use another language, then this
      mode is perfectly adequate.
      
      ASCII-CI is implemented by generating hashes based on lower-case letters
      and doing lower-case compares. It implements a new xfs_nameops vector for
      doing the hashes and comparisons for all filename operations.
      
      To create a filesystem with this CI mode, use: # mkfs.xfs -n version=ci
      <device>
      
      SGI-PV: 981516
      SGI-Modid: xfs-linux-melb:xfs-kern:31209a
      Signed-off-by: NBarry Naujok <bnaujok@sgi.com>
      Signed-off-by: NChristoph Hellwig <hch@infradead.org>
      189f4bf2
  2. 29 4月, 2008 2 次提交
  3. 10 4月, 2008 1 次提交
  4. 14 2月, 2008 1 次提交
  5. 07 2月, 2008 1 次提交
  6. 16 10月, 2007 2 次提交
  7. 15 10月, 2007 1 次提交
    • C
      [XFS] superblock endianess annotations · 2bdf7cd0
      Christoph Hellwig 提交于
      Creates a new xfs_dsb_t that is __be annotated and keeps xfs_sb_t for the
      incore one. xfs_xlatesb is renamed to xfs_sb_to_disk and only handles the
      incore -> disk conversion. A new helper xfs_sb_from_disk handles the other
      direction and doesn't need the slightly hacky table-driven approach
      because we only ever read the full sb from disk.
      
      The handling of shared r/o filesystems has been buggy on little endian
      system and fixing this required shuffling around of some code in that
      area.
      
      SGI-PV: 968563
      SGI-Modid: xfs-linux-melb:xfs-kern:29477a
      Signed-off-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NDavid Chinner <dgc@sgi.com>
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      2bdf7cd0
  8. 14 7月, 2007 5 次提交
    • D
      [XFS] Concurrent Multi-File Data Streams · 2a82b8be
      David Chinner 提交于
      In media spaces, video is often stored in a frame-per-file format. When
      dealing with uncompressed realtime HD video streams in this format, it is
      crucial that files do not get fragmented and that multiple files a placed
      contiguously on disk.
      
      When multiple streams are being ingested and played out at the same time,
      it is critical that the filesystem does not cross the streams and
      interleave them together as this creates seek and readahead cache miss
      latency and prevents both ingest and playout from meeting frame rate
      targets.
      
      This patch set creates a "stream of files" concept into the allocator to
      place all the data from a single stream contiguously on disk so that RAID
      array readahead can be used effectively. Each additional stream gets
      placed in different allocation groups within the filesystem, thereby
      ensuring that we don't cross any streams. When an AG fills up, we select a
      new AG for the stream that is not in use.
      
      The core of the functionality is the stream tracking - each inode that we
      create in a directory needs to be associated with the directories' stream.
      Hence every time we create a file, we look up the directories' stream
      object and associate the new file with that object.
      
      Once we have a stream object for a file, we use the AG that the stream
      object point to for allocations. If we can't allocate in that AG (e.g. it
      is full) we move the entire stream to another AG. Other inodes in the same
      stream are moved to the new AG on their next allocation (i.e. lazy
      update).
      
      Stream objects are kept in a cache and hold a reference on the inode.
      Hence the inode cannot be reclaimed while there is an outstanding stream
      reference. This means that on unlink we need to remove the stream
      association and we also need to flush all the associations on certain
      events that want to reclaim all unreferenced inodes (e.g. filesystem
      freeze).
      
      SGI-PV: 964469
      SGI-Modid: xfs-linux-melb:xfs-kern:29096a
      Signed-off-by: NDavid Chinner <dgc@sgi.com>
      Signed-off-by: NBarry Naujok <bnaujok@sgi.com>
      Signed-off-by: NDonald Douwsma <donaldd@sgi.com>
      Signed-off-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      Signed-off-by: NVlad Apostolov <vapo@sgi.com>
      2a82b8be
    • 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
    • T
      [XFS] Log the agf_length change in xfs_growfs_data_private(). · 0164af51
      Tim Shimmin 提交于
      SGI-PV: 963528
      SGI-Modid: xfs-linux-melb:xfs-kern:28856a
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      Signed-off-by: NDavid Chinner <dgc@sgi.com>
      Signed-off-by: NChristoph Hellwig <hch@infradead.org>
      0164af51
    • D
      [XFS] Lazy Superblock Counters · 92821e2b
      David Chinner 提交于
      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: NDavid Chinner <dgc@sgi.com>
      Signed-off-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      92821e2b
    • N
      [XFS] Don't grow filesystems past the size they can index. · 4cc929ee
      Nathan Scott 提交于
      When growing a filesystem we don't check to see if the new size overflows
      the page cache index range, so we can do silly things like grow a
      filesystem page 16TB on a 32bit. Check new filesystem sizes against the
      limits the kernel can support.
      
      SGI-PV: 957886
      SGI-Modid: xfs-linux-melb:xfs-kern:28563a
      Signed-Off-By: NNathan Scott <nscott@aconex.com>
      Signed-off-by: NDavid Chinner <dgc@sgi.com>
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      4cc929ee
  9. 08 5月, 2007 1 次提交
  10. 10 2月, 2007 2 次提交
    • E
      [XFS] Remove unused arguments from the XFS_BTREE_*_ADDR macros. · 2c36dded
      Eric Sandeen 提交于
      It makes it incrementally clearer to read the code when the top of a macro
      spaghetti-pile only receives the 3 arguments it uses, rather than 2 extra
      ones which are not used. Also when you start pulling this thread out of
      the sweater (i.e. remove unused args from XFS_BTREE_*_ADDR), a couple
      other third arms etc fall off too. If they're not used in the macro, then
      they sometimes don't need to be passed to the function calling the macro
      either, etc....
      
      Patch provided by Eric Sandeen (sandeen@sandeen.net).
      
      SGI-PV: 960197
      SGI-Modid: xfs-linux-melb:xfs-kern:28037a
      Signed-off-by: NEric Sandeen <sandeen@sandeen.net>
      Signed-off-by: NDavid Chinner <dgc@sgi.com>
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      2c36dded
    • D
      [XFS] Fix block reservation mechanism. · dbcabad1
      David Chinner 提交于
      The block reservation mechanism has been broken since the per-cpu
      superblock counters were introduced. Make the block reservation code work
      with the per-cpu counters by syncing the counters, snapshotting the amount
      of available space and then doing a modifcation of the counter state
      according to the result. Continue in a loop until we either have no space
      available or we reserve some space.
      
      SGI-PV: 956323
      SGI-Modid: xfs-linux-melb:xfs-kern:27895a
      Signed-off-by: NDavid Chinner <dgc@sgi.com>
      Signed-off-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      dbcabad1
  11. 07 9月, 2006 1 次提交
    • D
      [XFS] Prevent free space oversubscription and xfssyncd looping. · 4be536de
      David Chinner 提交于
      The fix for recent ENOSPC deadlocks introduced certain limitations on
      allocations. The fix could cause xfssyncd to loop endlessly if we did not
      leave some space free for the allocator to work correctly. Basically, we
      needed to ensure that we had at least 4 blocks free for an AG free list
      and a block for the inode bmap btree at all times.
      
      However, this did not take into account the fact that each AG has a free
      list that needs 4 blocks. Hence any filesystem with more than one AG could
      cause oversubscription of free space and make xfssyncd spin forever trying
      to allocate space needed for AG freelists that was not available in the
      AG.
      
      The following patch reserves space for the free lists in all AGs plus the
      inode bmap btree which prevents oversubscription. It also prevents those
      blocks from being reported as free space (as they can never be used) and
      makes the SMP in-core superblock accounting code and the reserved block
      ioctl respect this requirement.
      
      SGI-PV: 955674
      SGI-Modid: xfs-linux-melb:xfs-kern:26894a
      Signed-off-by: NDavid Chinner <dgc@sgi.com>
      Signed-off-by: NDavid Chatterton <chatz@sgi.com>
      4be536de
  12. 20 6月, 2006 1 次提交
  13. 09 6月, 2006 3 次提交
  14. 29 3月, 2006 1 次提交
  15. 14 3月, 2006 1 次提交
  16. 15 1月, 2006 1 次提交
  17. 11 1月, 2006 1 次提交
  18. 25 11月, 2005 1 次提交
  19. 02 11月, 2005 5 次提交
  20. 21 6月, 2005 1 次提交
  21. 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