1. 13 8月, 2013 2 次提交
  2. 31 5月, 2013 2 次提交
  3. 09 11月, 2012 3 次提交
  4. 08 11月, 2012 1 次提交
  5. 09 7月, 2011 1 次提交
  6. 19 10月, 2010 2 次提交
  7. 03 9月, 2010 1 次提交
    • T
      xfs: Make fiemap work with sparse files · 9af25465
      Tao Ma 提交于
      In xfs_vn_fiemap, we set bvm_count to fi_extent_max + 1 and want
      to return fi_extent_max extents, but actually it won't work for
      a sparse file. The reason is that in xfs_getbmap we will
      calculate holes and set it in 'out', while out is malloced by
      bmv_count(fi_extent_max+1) which didn't consider holes. So in the
      worst case, if 'out' vector looks like
      [hole, extent, hole, extent, hole, ... hole, extent, hole],
      we will only return half of fi_extent_max extents.
      
      This patch add a new parameter BMV_IF_NO_HOLES for bvm_iflags.
      So with this flags, we don't use our 'out' in xfs_getbmap for
      a hole. The solution is a bit ugly by just don't increasing
      index of 'out' vector. I felt that it is not easy to skip it
      at the very beginning since we have the complicated check and
      some function like xfs_getbmapx_fix_eof_hole to adjust 'out'.
      
      Cc: Dave Chinner <david@fromorbit.com>
      Signed-off-by: NTao Ma <tao.ma@oracle.com>
      Signed-off-by: NAlex Elder <aelder@sgi.com>
      9af25465
  8. 06 3月, 2010 1 次提交
  9. 21 9月, 2009 1 次提交
  10. 08 6月, 2009 1 次提交
  11. 10 1月, 2009 1 次提交
  12. 02 12月, 2008 1 次提交
  13. 01 12月, 2008 2 次提交
    • E
      [XFS] Add new getbmap flags. · 5af317c9
      Eric Sandeen 提交于
      This adds a new output flag, BMV_OF_LAST to indicate if we've hit
      the last extent in the inode.  This potentially saves an extra call
      from userspace to see when the whole mapping is done.
      
      It also adds BMV_IF_DELALLOC and BMV_OF_DELALLOC to request, and
      indicate, delayed-allocation extents.  In this case bmv_block
      is set to -2 (-1 was already taken for HOLESTARTBLOCK; unfortunately
      these are the reverse of the in-kernel constants.)
      
      These new flags facilitate addition of the new fiemap interface.
      
      Rather than adding sh_delalloc, remove sh_unwritten & just test
      the flags directly.
      Signed-off-by: NEric Sandeen <sandeen@sandeen.net>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NNiv Sardi <xaiki@sgi.com>
      5af317c9
    • E
      [XFS] convert xfs_getbmap to take formatter functions · 8a7141a8
      Eric Sandeen 提交于
      Preliminary work to hook up fiemap, this allows us to pass in an
      arbitrary formatter to copy extent data back to userspace.
      
      The formatter takes info for 1 extent, a pointer to the user "thing*"
      and a pointer to a "filled" variable to indicate whether a userspace
      buffer did get filled in (for fiemap, hole "extents" are skipped).
      
      I'm just using the getbmapx struct as a "common denominator" because
      as far as I can see, it holds all info that any formatters will care
      about.
      
      ("*thing" because fiemap doesn't pass the user pointer around, but rather
      has a pointer to a fiemap info structure, and helpers associated with it)
      Signed-off-by: NEric Sandeen <sandeen@sandeen.net>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NNiv Sardi <xaiki@sgi.com>
      8a7141a8
  14. 28 7月, 2008 2 次提交
    • C
      [XFS] attrmulti cleanup · e182f57a
      Christoph Hellwig 提交于
      xfs_attrmulti_by_handle currently request the size based on
      sizeof(attr_multiop_t) but should be using sizeof(xfs_attr_multiop_t)
      because that is what it is dealing with. Despite beeing wrong this
      actually harmless in practice because both structures are the same size on
      all platforms.
      
      But this sizeof was the only user of struct attr_multiop so we can just
      kill it. Also move the ATTR_OP_* defines xfs_attr.h into the struct
      xfs_attr_multiop defintion in xfs_fs.h because they are only used with
      that structure, and are part of the user ABI for the
      XFS_IOC_ATTRMULTI_BY_HANDLE ioctl.
      
      SGI-PV: 983508
      
      SGI-Modid: xfs-linux-melb:xfs-kern:31352a
      Signed-off-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      e182f57a
    • 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
  15. 07 2月, 2008 1 次提交
    • E
      [XFS] fix 32-bit compat ioctls for GETXFLAGS, SETXFLAGS, GETVERSION · bc58f9bb
      Eric Sandeen 提交于
      XFS_IOC_GETVERSION, XFS_IOC_GETXFLAGS and XFS_IOC_SETXFLAGS all take a
      "long" which changes size between 32 and 64 bit platforms.
      
      So, the ioctl cmds that come in from a 32-bit app aren't as expected, for
      example on GETXFLAGS,
      
      unknown cmd fd(3) cmd(80046601){t:'f';sz:4}
      
      due to the size mismatch.
      
      So, use instead the 32-bit version of the commands for compat ioctls, and
      other than that it doesn't take any more manipulation.
      
      Also, for both native and compat versions, just define them to the values
      as defined in fs.h
      
      SGI-PV: 971186
      SGI-Modid: xfs-linux-melb:xfs-kern:29849a
      Signed-off-by: NEric Sandeen <sandeen@sandeen.net>
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      bc58f9bb
  16. 19 10月, 2007 1 次提交
    • C
      [XFS] cleanup fid types mess · c6143911
      Christoph Hellwig 提交于
      Currently XFs has three different fid types: struct fid, struct xfs_fid
      and struct xfs_fid2 with hte latter two beeing identicaly and the first
      one beeing the same size but an unstructured array with the same size.
      
      This patch consolidates all this to alway uuse struct xfs_fid.
      
      This patch is required for an upcoming patch series from me that revamps
      the nfs exporting code and introduces a Linux-wide struct fid.
      
      SGI-PV: 970336
      SGI-Modid: xfs-linux-melb:xfs-kern:29651a
      Signed-off-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      Signed-off-by: NTim Shimmin <tes@sgi.com>
      c6143911
  17. 14 7月, 2007 2 次提交
    • 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] 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
  18. 28 9月, 2006 1 次提交
  19. 09 6月, 2006 2 次提交
  20. 11 1月, 2006 2 次提交
  21. 02 11月, 2005 2 次提交
  22. 21 6月, 2005 2 次提交
  23. 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