Eric Sandeen wrote:
> Andrew Morton wrote:
>> On Wed, 14 Jan 2009 22:06:17 -0600
>> Eric Sandeen <sandeen@xxxxxxxxxx> 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 guess that if the sync is blocked on a frozen fs then things will
>> sort themselves out.
>>
>> otoh, if all the pdflush threads are blocked on frozen filesystems
>> (possible?) then the emergency_thaw() simply won't do anything.
>
> Hm, maybe possible... I'll have to think about that.
Oh, actually, I'd think not. If the freeze was done properly by the
filesystem, all data was flushed, the fs was quiesced, and new IO was
blocked. pdflush should never be visiting these...
In fact emergency sync is kind of orthogonal to emergency thaw, anything
which needs a thaw should never actually need a sync.
-Eric
> Thanks,
> -Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
