From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: David Chinner <dgc@sgi.com>,
xfs-masters@oss.sgi.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: freeze vs freezer
Date: Mon, 26 Nov 2007 10:44:20 -0800 [thread overview]
Message-ID: <474B1404.8020800@goop.org> (raw)
In-Reply-To: <200711240047.21624.rjw@sisk.pl>
Rafael J. Wysocki wrote:
> On Thursday, 22 of November 2007, Jeremy Fitzhardinge wrote:
>
>> It seems that a process blocked in a write to an xfs filesystem due to
>> xfs_freeze cannot be frozen by the freezer.
>>
>
> The freezer doesn't handle tasks in TASK_UNINTERRUPTIBLE and I don't know how
> to make it handle them without at least partially defeating its purpose.
>
Well, I guess the question is whether an xfs-frozen writer really needs
to be UNINTERRUPTIBLE from the freezer's perspective (clearly it does
from usermode's perspective - filesystem writes just don't return EINTR).
>From a quick poke around, it looks to me like freezing is actually
implemented in the VFS layer rather than in XFS itself: is that right?
Could vfs_check_frozen() be changed to something that is freezer-compatible?
>> I see this if I suspend my laptop while doing something xfs-filesystem
>> intensive, like a kernel build. My suspend scripts freeze the XFS
>> filesystem (as Dave said I should), which presumably blocks some writer,
>> and then the freezer times out and fails to complete.
>>
>> Here's part of the process dump the freezer does when it times out:
>>
>> cc1 D 00000000 0 18138 18137
>> dd5f1e24 00200082 00000002 00000000 ecdeeb00 ecdeec64 c200f280 00000001
>> 009c09a0 dd5f1e0c dd5f1e0c 0000000f 00000000 00000000 00000000 dd5f1e74
>> c7beb480 dd5f1e88 dd5f1ea8 c0228d97 e8889540 dd5f1e38 c015b75d dd5f1e44
>> Call Trace:
>> [<c0228d97>] xfs_write+0xf4/0x6d9
>> [<c0226038>] xfs_file_aio_write+0x53/0x5b
>> [<c0171c15>] do_sync_write+0xae/0xec
>> [<c0172343>] vfs_write+0xa4/0x120
>> [<c01728d7>] sys_write+0x3b/0x60
>> [<c0106fae>] sysenter_past_esp+0x6b/0xa1
>> =======================
>>
>>
>> I haven't looked at how to fix this yet. I only just worked out why I
>> was getting suspend failures.
>>
>
> Well, you can add freezer_do_not_count()/freezer_count() annotations to
> xfs_write() (and whatever else is blocked as a result of the XFS being frozen).
>
What would be the implications of that? Would that just prevent
freezing while there's something blocked there?
> Generally, that would be risky without the freezing of XFS, however, because it
> might leak us filesystem data to a storage device after creating a hibernation
> image which would result in the filesystem corruption after the resume.
>
> Still, if you only suspend to RAM, that should be safe.
>
I specifically added it because I was getting data loss due to crashes
during suspend/resume problems. It's been pretty stable lately, but I
may as well remove the xfs_freeze from my suspend scripts if this is the
solution.
I think the broader issue is that there's no reason in principle why
something blocked due to xfs-freezing (or vfs freezing) should prevent
the freezer from completing.
J
next prev parent reply other threads:[~2007-11-26 18:44 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-22 3:54 freeze vs freezer Jeremy Fitzhardinge
2007-11-23 23:47 ` Rafael J. Wysocki
2007-11-26 18:44 ` Jeremy Fitzhardinge [this message]
2007-11-26 21:20 ` Rafael J. Wysocki
2007-11-26 21:17 ` David Chinner
2007-11-26 21:53 ` Rafael J. Wysocki
2007-11-27 5:38 ` Matthew Garrett
2007-11-27 17:40 ` Rafael J. Wysocki
2007-11-27 20:33 ` Kyle Moffett
2007-11-27 23:01 ` Rafael J. Wysocki
2007-11-27 22:49 ` Jeremy Fitzhardinge
2007-11-27 23:14 ` Kyle Moffett
2007-11-27 23:32 ` Jeremy Fitzhardinge
2008-01-02 16:02 ` Pavel Machek
2008-01-02 21:30 ` Nigel Cunningham
2008-01-02 22:04 ` Rafael J. Wysocki
2008-01-03 9:19 ` Nigel Cunningham
2008-01-03 9:47 ` Oliver Neukum
2008-01-03 9:52 ` Nigel Cunningham
2008-01-03 11:15 ` Oliver Neukum
2008-01-03 22:06 ` Nigel Cunningham
2008-01-04 20:54 ` Oliver Neukum
2008-01-05 1:38 ` Kyle Moffett
2008-01-05 21:18 ` Pavel Machek
2008-01-05 23:01 ` Nigel Cunningham
2008-01-03 22:31 ` Rafael J. Wysocki
2008-06-23 7:16 ` Pavel Machek
2008-06-23 14:00 ` Henrique de Moraes Holschuh
2008-06-24 8:08 ` Elias Oltmanns
2008-06-26 15:09 ` Pavel Machek
2008-06-29 22:12 ` [xfs-masters] " Dave Chinner
2008-06-29 23:22 ` Rafael J. Wysocki
2008-06-30 6:11 ` Christoph Hellwig
2008-06-30 20:34 ` Rafael J. Wysocki
2008-07-03 19:43 ` Eric Sandeen
2008-06-30 6:29 ` Dave Chinner
2008-06-30 6:37 ` Jeremy Fitzhardinge
2008-06-30 12:33 ` Dave Chinner
2008-06-30 21:00 ` Rafael J. Wysocki
2008-06-30 22:21 ` Dave Chinner
2008-06-30 22:38 ` Rafael J. Wysocki
2008-07-01 6:38 ` Dave Chinner
2008-07-01 14:35 ` Rafael J. Wysocki
2008-07-01 15:05 ` Elias Oltmanns
2008-07-01 15:17 ` Christoph Hellwig
2008-07-01 21:15 ` Dave Chinner
2008-07-01 21:46 ` Elias Oltmanns
2008-07-01 21:12 ` Dave Chinner
2008-07-01 21:21 ` Rafael J. Wysocki
2008-07-01 8:59 ` Pavel Machek
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=474B1404.8020800@goop.org \
--to=jeremy@goop.org \
--cc=dgc@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=xfs-masters@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.