public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard@openedhand.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: kernel list <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Hugh Dickins <hugh@veritas.com>
Subject: Re: [PATCH, RFC/T] Fix handling of write failures to swap devices
Date: Wed, 01 Nov 2006 09:32:49 +0000	[thread overview]
Message-ID: <1162373569.5564.16.camel@localhost.localdomain> (raw)
In-Reply-To: <45483278.1080603@yahoo.com.au>

On Wed, 2006-11-01 at 16:36 +1100, Nick Piggin wrote:
> Also note that the current code *should* "gracefully" handle the failure.
> In that, it will not reclaim the page on a write error, so it isn't going
> to cause a data loss...
> 
> It's just that it currently results in unswappable pages.
> 
> Handling it more gracefully by allowing the page to be retried with another
> swap entry is OK I guess, but given the added complexity, I'm not even sure
> it is worthwhile.
> 
> Perhaps we should just do the ClearPageError in the try_to_unuse path,
> because the sysadmin should take down that swap device on failure. So if a
> new device is added, we want to be able to unpin the failed pages.

As I see it, ClearPageError in the try_to_unuse path is the correct
thing to do as once we've marked the swap page as bad, it can't retry to
the same swap page. There is nothing special about the failed pages
beyond that point so we don't need them marked.

Also, if we remove the error flag, the page is still probably on the
inactive list so other existing code is likely to take care of trying a
new write to a another swap entry? I didn't add code for this case for
that reason.

Regards,

Richard


  reply	other threads:[~2006-11-01  9:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-27  7:59 [PATCH, RFC/T] Fix handling of write failures to swap devices Richard Purdie
2006-10-27  8:22 ` Nick Piggin
2006-10-27  8:44   ` Richard Purdie
2006-10-28  4:55     ` Nick Piggin
2006-10-28 10:43       ` Richard Purdie
2006-10-28 12:10         ` Nick Piggin
2006-10-30 11:55           ` Richard Purdie
2006-11-01  5:26             ` Nick Piggin
2006-11-01  9:24               ` Richard Purdie
2006-11-02 23:26               ` Richard Purdie
2006-12-13 11:43               ` Richard Purdie
2006-11-01  5:36             ` Nick Piggin
2006-11-01  9:32               ` Richard Purdie [this message]
2006-10-27  9:35   ` Richard Purdie
2006-10-27 21:19 ` Andrew Morton

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=1162373569.5564.16.camel@localhost.localdomain \
    --to=richard@openedhand.com \
    --cc=akpm@osdl.org \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    /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