On 09/24/2009 12:07 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID:
On Thursday, 2009-09-24 at 08:57 +0200, Takashi Iwai wrote:
At Wed, 23 Sep 2009 17:52:38 -0700, Jeff Mahoney wrote:
ReiserFS hasn't really changed and neither has grub. Rafael's diagnosis in the bugzilla entry is probably right though. It's probably replaying the journal, which really just means traversing it and building a mapping table. It doesn't actually write anything. The big problem to figure out is why it's leaving loads of open transactions open in the journal for an operation that should be "clean."
Notice that the problem I reported is grub being very slow in loading the kernel. Once the the initial kernel starts booting, it boots fast, it sees the loaded swap partition and reload the swapped out system, fast. You can watch the sequence in the video I recorded.
And the weird thing with your explanation is that grub should not replay the log, should it? I thought that was something reserved for reiserfsck during init?
IIRC, it's just a long-standing issue of reiserfs support in GRUB. After S2D, it's still not 100% "clean" as GRUB believes, so it replays journal.
Can grub replay the journal? :-?
It doesn't replay it in the sense you're thinking. It scans it and creates a block mapping, so it gets the effect of replaying the journal but in a read-only manner. So, say block 100000 would be overwritten at journal replay, we'd redirect the read of that block to the newest copy of it in the journal. We *have* to do this. That's the entire point of a journaling file system - otherwise, grub could end up trying to read incomplete metadata.
The best solution would be to fix/improve GRUB, but this would happen unlikely. A classical solution is to create only a small /boot partition with ext2 or ext3 and the rest with reiserfs.
Yes, that is what I'll try this weekend, time permitting: I'll move /boot to a separate ext2 partition (which I have available) and report back; I just wanted to warn people using reiserfs as root filesystem that there may be problems.
And IMO, YaST should warn.
The real issue is in the kernel, IMO. s2disk should be flushing the journal. We have ways of doing that so (without having looked at the suspend code), it should be possible to do. -Jeff -- Jeff Mahoney SuSE Labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org