[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49DBA87F.6070501@rtr.ca>
Date: Tue, 07 Apr 2009 15:24:47 -0400
From: Mark Lord <lkml@....ca>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ray Lee <ray-lk@...rabbit.org>, Hua Zhong <hzhong@...il.com>,
Theodore Tso <tytso@....edu>,
Jens Axboe <jens.axboe@...cle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/8][RFC] IO latency/throughput fixes
Linus Torvalds wrote:
>
> On Tue, 7 Apr 2009, Mark Lord wrote:
>> What happens with ext3 "writeback", and ext4 "whatever",
>> when one does the quickie reboot method:
>>
>> ALT-SYSRQ-S ALT-SYSRQ-U ALT-SYSRQ-S ALT-SYSRQ-B
>>
>> ???
>
> Since 's' syncs (I think 'u' does too, as part of making things
> read-only), the data blocks will be on disk after the boot regardless of
> any other ordering.
..
I was thinking more about delayed allocation in ext4, though.
If it hasn't allocated the blocks, then sync() has nothing to write out.
Or do they have hooks into the block layer to force alloc/commit when
somebody does a sync() ??
> Of course, it will leave all your lock-files files alone, and I can almost
> guarantee that some daemons (read: "NetworkManager") will then fail on the
> next boot because they think they are already running.
..
No, it behaves fine on reboot here. But actually, NM is one big reason
why I end up having to use the ALT-SYSRQ-S/U/S/B.
The Ubunutu reboot scripts seem broken at times w.r.t. NM --
it hangs the reboot sequence on some of my machines here
for a very long time (during shutdown), because (I think)
the scripts disable the interface before disabling NM.. Doh!
Seems happy enough after rebooting though.
Cheers
--
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