public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com
Subject: [PATCH 0/8] xfs: clean up unit usage in xfs_buf V2
Date: Thu, 29 Mar 2012 23:23:47 +1100	[thread overview]
Message-ID: <1333023835-12856-1-git-send-email-david@fromorbit.com> (raw)

This series cleans up the buffer cache API to use daddr formats for
block numbers and basic blocks for lengths when trying to get or
read a buffer and from there cleans up the internal usage of the
same thing. Essentially we end up with tracking buffers by their
daddr blkno, and BB based length, including the length of the IO
needed to do out of the buffer. The b_offset field is still in
bytes, as that is mostly used as a byte offset into the allocated
memory that the buffer holds, rather than a disk based offset.

Version 2:
- new patch 1, fixes hang in log reading code when trying to find
  the head and IO dispatch returns EIO. Generic fix for the same
  problem for all IO dispatched via xfsbdstrat() and then waited on
  via xfs_buf_iowait().
- new patch 2, fixes EIO during IO dispatch reading uncached buffers
  when page size unaligned, subpage-sized multi-block buffers are
  incorrectly required to need multiple pages due to invalid
  b_offset. This was triggered by log recovery when finding the head
  of the log, and caused the hang fixed in patch 1. Problem was
  reliably triggered by patch 5, though there is no obvious reason
  that I can find for any of those changes to have tripped over this
  landmine.
- new patch 3, clean, noticed when trying to work out why b_offset
  wasn't zero find the problem fixed in patch 2.
- patch 4-7, updated according to Christoph's comments
- new patch 8, kills the xfs_buf_btoc (and related) macros as
  suggested by Christoph.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

             reply	other threads:[~2012-03-29 12:24 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-29 12:23 Dave Chinner [this message]
2012-03-29 12:23 ` [PATCH 1/8] xfs: check for buffer errors before waiting Dave Chinner
2012-03-29 19:04   ` Mark Tinguely
2012-03-29 21:10     ` Dave Chinner
2012-03-29 21:48       ` Mark Tinguely
2012-03-29 22:07         ` Dave Chinner
2012-03-29 19:12   ` Christoph Hellwig
2012-03-29 21:17     ` Dave Chinner
2012-03-29 12:23 ` [PATCH 2/8] xfs: fix incorrect b_offset initialisation Dave Chinner
2012-03-29 19:13   ` Christoph Hellwig
2012-03-29 20:43   ` Mark Tinguely
2012-03-29 12:23 ` [PATCH 3/8] xfs: use kmem_zone_zalloc for buffers Dave Chinner
2012-03-29 19:14   ` Christoph Hellwig
2012-03-29 20:45   ` Mark Tinguely
2012-03-29 12:23 ` [PATCH 4/8] xfs: clean up buffer get/read call API Dave Chinner
2012-03-30 19:12   ` Mark Tinguely
2012-03-29 12:23 ` [PATCH 5/8] xfs: kill b_file_offset Dave Chinner
2012-03-30 19:12   ` Mark Tinguely
2012-03-29 12:23 ` [PATCH 6/8] xfs: use blocks for counting length of buffers Dave Chinner
2012-03-29 19:16   ` Christoph Hellwig
2012-03-30 19:13   ` Mark Tinguely
2012-03-29 12:23 ` [PATCH 7/8] xfs: use blocks for storing the desired IO size Dave Chinner
2012-03-30 19:13   ` Mark Tinguely
2012-03-29 12:23 ` [PATCH 8/8] xfs: kill xfs_buf_btoc Dave Chinner
2012-03-29 19:18   ` Christoph Hellwig
2012-03-30 19:13   ` Mark Tinguely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1333023835-12856-1-git-send-email-david@fromorbit.com \
    --to=david@fromorbit.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox