From: Dave Chinner <david@fromorbit.com>
To: Alex Elder <aelder@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH v2] xfs: Don't flush stale inodes
Date: Sat, 9 Jan 2010 11:09:27 +1100 [thread overview]
Message-ID: <20100109000927.GE8654@discord.disaster> (raw)
In-Reply-To: <1AB9A794DBDDF54A8A81BE2296F7BDFE012A693A@cf--amer001e--3.americas.sgi.com>
On Fri, Jan 08, 2010 at 05:14:25PM -0600, Alex Elder wrote:
> Dave Chinner wrote:
> > Because inodes remain in cache much longer than inode buffers do
> > under memory pressure, we can get the situation where we have stale,
> > dirty inodes being reclaimed but the backing storage has been freed.
> > Hence we should never, ever flush XFS_ISTALE inodes to disk as
> > there is no guarantee that the backing buffer is in cache and
> > still marked stale when the flush occurs.
> >
> > Signed-off-by: Dave Chinner <david@fromorbit.com>
>
> Dave, I'm putting this patch in before your perag radix tree
> patch series, so I had to port it. I am submitting here on
> your behalf, but would like you to review it if possible.
> It builds fine, and I've run it through a quick test.
> I will retain all of your original commentary, etc. I did
> *not* implement Christoph's recommendation that you change
> the "for" loop in xfs_alloc_search_busy() to a more typical
> form.
>
> For reference, the original patch is here:
> http://patchwork.xfs.org/patch/382/
>
> Signed-off-by: Alex Elder <aelder@sgi.com>
Ah, which patch are you talking about? The title says stale inodes,
the patch is searching busy extents.
Assuming you meant the busy extent search fix, you've ported the
wrong version of the busy extent search fix. I posted an updated
version after Christoph reviewed that one (in my response to
Christoph's review).
Because it was a new patch, patchwork doesn't add the email to the
original thread - it starts a new one. It's a real PITA, IMO, but
that is the way patchwork does stuff. The patch that should be
checked in is this one:
http://patchwork.xfs.org/patch/387/
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-01-09 0:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-02 2:39 [PATCH] XFS: Don't flush stale inodes Dave Chinner
2010-01-02 12:00 ` Christoph Hellwig
2010-01-02 12:14 ` Dave Chinner
2010-01-02 12:24 ` Dave Chinner
2010-01-02 13:17 ` Christoph Hellwig
2010-01-02 13:39 ` Dave Chinner
2010-01-08 20:59 ` Alex Elder
2010-01-08 23:14 ` [PATCH v2] xfs: " Alex Elder
2010-01-09 0:09 ` Dave Chinner [this message]
2010-01-09 16:22 ` Alex Elder
2010-01-09 22:39 ` Dave Chinner
2010-01-10 16:43 ` Alex Elder
2010-01-09 18:10 ` [PATCH, updated] xfs: Ensure we force all busy extents in range to disk Alex Elder
2010-01-09 19:35 ` Christoph Hellwig
2010-01-10 18:28 ` [PATCH, updated] xfs: Ensure we force all busy extents inrange " Alex Elder
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=20100109000927.GE8654@discord.disaster \
--to=david@fromorbit.com \
--cc=aelder@sgi.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