1. 25 Jun, 2014 1 commit
  2. 23 Oct, 2013 2 commits
    • Dave Chinner's avatar
      xfs: decouple inode and bmap btree header files · a4fbe6ab
      Dave Chinner authored
      Currently the xfs_inode.h header has a dependency on the definition
      of the BMAP btree records as the inode fork includes an array of
      xfs_bmbt_rec_host_t objects in it's definition.
      Move all the btree format definitions from xfs_btree.h,
      xfs_bmap_btree.h, xfs_alloc_btree.h and xfs_ialloc_btree.h to
      xfs_format.h to continue the process of centralising the on-disk
      format definitions. With this done, the xfs inode definitions are no
      longer dependent on btree header files.
      The enables a massive culling of unnecessary includes, with close to
      200 #include directives removed from the XFS kernel code base.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBen Myers <bpm@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
    • Dave Chinner's avatar
      xfs: create a shared header file for format-related information · 70a9883c
      Dave Chinner authored
      All of the buffer operations structures are needed to be exported
      for xfs_db, so move them all to a common location rather than
      spreading them all over the place. They are verifying the on-disk
      format, so while xfs_format.h might be a good place, it is not part
      of the on disk format.
      Hence we need to create a new header file that we centralise these
      related definitions. Start by moving the bffer operations
      structures, and then also move all the other definitions that have
      crept into xfs_log_format.h and xfs_format.h as there was no other
      shared header file to put them in.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
  3. 21 Apr, 2013 1 commit
    • Christoph Hellwig's avatar
      xfs: add support for large btree blocks · ee1a47ab
      Christoph Hellwig authored
      Add support for larger btree blocks that contains a CRC32C checksum,
      a filesystem uuid and block number for detecting filesystem
      consistency and out of place writes.
      [dchinner@redhat.com] Also include an owner field to allow reverse
      mappings to be implemented for improved repairability and a LSN
      field to so that log recovery can easily determine the last
      modification that made it to disk for each buffer.
      [dchinner@redhat.com] Add buffer log format flags to indicate the
      type of buffer to recovery so that we don't have to do blind magic
      number tests to determine what the buffer is.
      [dchinner@redhat.com] Modified to fit into the verifier structure.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBen Myers <bpm@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
  4. 16 Nov, 2012 1 commit
    • Dave Chinner's avatar
      xfs: convert buffer verifiers to an ops structure. · 1813dd64
      Dave Chinner authored
      To separate the verifiers from iodone functions and associate read
      and write verifiers at the same time, introduce a buffer verifier
      operations structure to the xfs_buf.
      This avoids the need for assigning the write verifier, clearing the
      iodone function and re-running ioend processing in the read
      verifier, and gets rid of the nasty "b_pre_io" name for the write
      verifier function pointer. If we ever need to, it will also be
      easier to add further content specific callbacks to a buffer with an
      ops structure in place.
      We also avoid needing to export verifier functions, instead we
      can simply export the ops structures for those that are needed
      outside the function they are defined in.
      This patch also fixes a directory block readahead verifier issue
      it exposed.
      This patch also adds ops callbacks to the inode/alloc btree blocks
      initialised by growfs. These will need more work before they will
      work with CRCs.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarPhil White <pwhite@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
  5. 01 Jul, 2012 1 commit
    • Dave Chinner's avatar
      xfs: struct xfs_buf_log_format isn't variable sized. · 77c1a08f
      Dave Chinner authored
      The struct xfs_buf_log_format wants to think the dirty bitmap is
      variable sized.  In fact, it is variable size on disk simply due to
      the way we map it from the in-memory structure, but we still just
      use a fixed size memory allocation for the in-memory structure.
      Hence it makes no sense to set the function up as a variable sized
      structure when we already know it's maximum size, and we always
      allocate it as such. Simplify the structure by making the dirty
      bitmap a fixed sized array and just using the size of the structure
      for the allocation size.
      This will make it much simpler to allocate and manipulate an array
      of format structures for discontiguous buffer support.
      The previous struct xfs_buf_log_item size according to
      /proc/slabinfo was 224 bytes. pahole doesn't give the same size
      because of the variable size definition. With this modification,
      pahole reports the same as /proc/slabinfo:
      	/* size: 224, cachelines: 4, members: 6 */
      Because the xfs_buf_log_item size is now determined by the maximum
      supported block size we introduce a dependency on xfs_alloc_btree.h.
      Avoid this dependency by moving the idefines for the maximum block
      sizes supported to xfs_types.h with all the other max/min type
      defines to avoid any new dependencies.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
  6. 30 Oct, 2008 11 commits
  7. 10 Feb, 2007 1 commit
    • Eric Sandeen's avatar
      [XFS] Remove unused arguments from the XFS_BTREE_*_ADDR macros. · 2c36dded
      Eric Sandeen authored
      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: default avatarEric Sandeen <sandeen@sandeen.net>
      Signed-off-by: default avatarDavid Chinner <dgc@sgi.com>
      Signed-off-by: default avatarTim Shimmin <tes@sgi.com>
  8. 02 Nov, 2005 3 commits
  9. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!