From: Nigel Cunningham <nigel@suspend2.net>
To: David Chinner <dgc@sgi.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Andrew Morton <akpm@osdl.org>,
LKML <linux-kernel@vger.kernel.org>, Pavel Machek <pavel@ucw.cz>
Subject: Re: [PATCH -mm 0/2] Use freezeable workqueues to avoid suspend-related XFS corruptions
Date: Mon, 20 Nov 2006 22:02:17 +1100 [thread overview]
Message-ID: <1164020537.10428.11.camel@nigel.suspend2.net> (raw)
In-Reply-To: <20061120001540.GX11034@melbourne.sgi.com>
Hi all.
I've did some testing this afternoon with bdev freezing disabled and
without any non-vanilla code to freeze kthreads (Rafael's or my older
version).
If I put a BUG_ON() in submit_bio for non suspend2 I/O, it catches this
trace:
submit_bio
xfs_buf_iorequest
xlog_bdstrat_cb
xlog_state_release_iclog
xlog_state_sync_all
xfs_log_force
xfs_syncsub
xfs_sync
vfs_sync
vfs_sync_worker
xfssyncd
keventd_create_kthread
I haven't yet reproduced anything on another code path (eg pdflush).
So, it would appear that freezing kthreads without freezing bdevs should
be a possible solution. It may however leave some I/O unsynced
pre-resume and therefore result in possible dataloss if no resume
occurs. I therefore wonder whether it's better to stick with bdev
freezing or create some variant wherein XFS is taught to fully flush
pending writes and not create new I/O.
Regards,
Nigel
next prev parent reply other threads:[~2006-11-20 11:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-16 8:12 [PATCH -mm 0/2] Use freezeable workqueues to avoid suspend-related XFS corruptions Rafael J. Wysocki
2006-11-16 8:15 ` [PATCH -mm 1/2] Support for freezeable workqueues Rafael J. Wysocki
2006-11-16 15:03 ` Pavel Machek
2006-11-16 8:18 ` [PATCH -mm 2/2] Use freezeable workqueues in XFS Rafael J. Wysocki
2006-11-16 15:05 ` Pavel Machek
2006-11-17 0:50 ` [PATCH -mm 0/2] Use freezeable workqueues to avoid suspend-related XFS corruptions David Chinner
2006-11-17 15:14 ` Pavel Machek
2006-11-17 16:19 ` Rafael J. Wysocki
2006-11-20 0:15 ` David Chinner
2006-11-20 11:02 ` Nigel Cunningham [this message]
2006-11-20 20:40 ` Rafael J. Wysocki
2006-11-20 22:03 ` Nigel Cunningham
2006-11-20 22:18 ` Rafael J. Wysocki
2006-11-20 22:26 ` Nigel Cunningham
2006-11-20 22:39 ` Nigel Cunningham
2006-11-20 22:55 ` Rafael J. Wysocki
2006-11-21 0:51 ` Nigel Cunningham
2006-11-21 11:19 ` Rafael J. Wysocki
2006-11-21 4:20 ` David Chinner
2006-11-20 20:12 ` Rafael J. Wysocki
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=1164020537.10428.11.camel@nigel.suspend2.net \
--to=nigel@suspend2.net \
--cc=akpm@osdl.org \
--cc=dgc@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
/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.