[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1232122907.15209.3.camel@norville.austin.ibm.com>
Date: Fri, 16 Jan 2009 10:21:47 -0600
From: Dave Kleikamp <shaggy@...ux.vnet.ibm.com>
To: Eric Sandeen <sandeen@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
t-sato@...jp.nec.com
Subject: Re: [PATCH] Allow SysRq emergency sync to thaw frozen filesystems
On Thu, 2009-01-15 at 21:49 -0600, Eric Sandeen wrote:
> Andrew Morton wrote:
> > On Wed, 14 Jan 2009 22:06:17 -0600
> > Eric Sandeen <sandeen@...hat.com> wrote:
> >> Index: linux-2.6/drivers/char/sysrq.c
> >> ===================================================================
> >> --- linux-2.6.orig/drivers/char/sysrq.c
> >> +++ linux-2.6/drivers/char/sysrq.c
> >> @@ -151,6 +151,7 @@ static struct sysrq_key_op sysrq_reboot_
> >>
> >> static void sysrq_handle_sync(int key, struct tty_struct *tty)
> >> {
> >> + emergency_thaw();
> >> emergency_sync();
> >> }
> >
> > Kind of weird. The thaw will happen after/during the sync().
>
> oh, hrm. Maybe I didn't think enough about how it's handed off to
> pdflush; I could rearrange if that makes sense? Or maybe handing to
> pdflush is wrong, it was just so convenient....
I don't understand the reason for handing it to pdflush. I would expect
thaw to be very fast. Do we expect it to block anywhere, and if so, for
very long? Not that I see any problem with it.
Shaggy
--
David Kleikamp
IBM Linux Technology Center
--
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