[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4541C1B2.7070003@yahoo.com.au>
Date: Fri, 27 Oct 2006 18:22:10 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Richard Purdie <rpurdie@...nedhand.com>
CC: kernel list <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...l.org>
Subject: Re: [PATCH, RFC/T] Fix handling of write failures to swap devices
Richard Purdie wrote:
> Fix handling of write failures to swap devices.
>
> Calling SetPageError(page) marks the data in memory as bad and processes using
> the page in question will die unexpectedly. This isn't necessary as the data
> in the memory page is still valid, just the copy on disk isn't. This patch
> therefore removes this call.
>
> Setting set_page_dirty(page) is good as the memory page will be retained and
> processes don't die. It will try to write out the page again soon but a second
> attempt at a write is probably no more likely to succeed than the first
> resulting in IO loops. We can do better.
>
> This patch attempts to unuse the page in a similar manner to swapoff. If
> successful, mark the swap page as bad and remove it from use. If we fail to
> remove all references, we fall back on set_page_dirty above which will retry
> the write.
>
> If we can mark the swap page as bad, adjust the VM accounting to reflect this.
>
> Signed-off-by: Richard Purdie <rpurdie@...nedhand.com>
>
> ---
>
> Comments and testing from people who know this area of code better than
> me would be appreciated!
This is the right approach to handling swap write errors. However, you need
to cut down on the amount of code duplication. Also, if you hit that BUG_ON,
then you probably have a bug, don't remove it!
Otherwise, this would be nice to have so it's great you're working on it,
thanks.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists