public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: David Chinner <dgc@sgi.com>
To: Nathan Scott <nathans@sgi.com>
Cc: Eric Sandeen <sandeen@sandeen.net>, dgc@sgi.com, xfs@oss.sgi.com
Subject: Re: [PATCH] kill no-op buf macros
Date: Wed, 9 Aug 2006 11:24:44 +1000	[thread overview]
Message-ID: <20060809012444.GS2114946@melbourne.sgi.com> (raw)
In-Reply-To: <20060731090815.B2280998@wobbly.melbourne.sgi.com>

On Mon, Jul 31, 2006 at 09:08:15AM +1000, Nathan Scott wrote:
> On Sat, Jul 29, 2006 at 10:41:09PM -0500, Eric Sandeen wrote:
> > It looks like these macros are not particularly interesting... this patch kills 
> > them.
> 
> Hmm, I'm not sure about some of these..
> 
> > #define XFS_BUF_BUSY(bp)	do { } while (0)
> > #define XFS_BUF_ISBUSY(bp)	(1)
> 
> This ones used on 2.4, I'd like to get Daves thoughts on whether
> we do the right thing here based on his buffer cache fu.

XFS_BUF_ISBUSY() is only ever used in ASSERT() statements, so I
think that can go. On 2.4:

#define XFS_BUF_BUSY(bp) ((bp)->b_flags |= XBF_FORCEIO)

The XBF_FORCEIO affects how we do partial page I/O on 2.4, but is
unused on 2.6. On 2.4, if the flag is set, we ignore the
buffer_uptodate() status of the buffers on the page and re-read all
the buffers in the range specified.  For writes, we always write all
the buffers on the page.

The flag is set when we issue direct I/O or in  xfs_buf_get_noaddr()
which is used to allocate log buffers and buffers for block zeroing.
This seems sane to me given the way we use bufferheads in 2.4....

> > #define XFS_BUF_SHUT(bp)	do { } while (0)
> > #define XFS_BUF_UNSHUT(bp)	do { } while (0)
> > #define XFS_BUF_ISSHUT(bp)	(0)
> 
> Ditto (not used on 2.4 though, but still maybe we should be doing
> something here).

IIRC, these were used to indicate that the buffers we're throwing
away on filesystem shutdown during I/O completion. This   is the
irix mechanism for throwing away delwri buffers on shutdown - we
don't use this on linux so I think we can kill these.

> > #define XFS_BUF_SET_START(bp)			do { } while (0)
> 
> Not sure what this used to do - Dave?

On Irix, that writes the current kernel time in to the buffer so
that the delwri flush code can tell when it is old enough to flush.
Wwe do that differently in linux, so this can be removed, methinks.

> > #define XFS_BUF_SET_VTYPE_REF(bp, type, ref)	do { } while (0)
> > #define XFS_BUF_SET_VTYPE(bp, type)		do { } while (0)
> > #define XFS_BUF_SET_REF(bp, ref)		do { } while (0)
> 
> These ones should probably be implemented properly, not removed.

*nod*

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

  parent reply	other threads:[~2006-08-09  1:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-30  3:41 [PATCH] kill no-op buf macros Eric Sandeen
2006-07-30 23:08 ` Nathan Scott
2006-07-31  0:25   ` Eric Sandeen
2006-07-31  4:03   ` Eric Sandeen
2006-08-09  1:24   ` David Chinner [this message]
2006-08-09  2:43     ` Eric Sandeen

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=20060809012444.GS2114946@melbourne.sgi.com \
    --to=dgc@sgi.com \
    --cc=nathans@sgi.com \
    --cc=sandeen@sandeen.net \
    --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