Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

From: Andrey Borzenkov
Date: Mon Nov 13 2006 - 23:07:58 EST


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 14 November 2006 01:58, Stefan Seyfried wrote:
> On Mon, Nov 13, 2006 at 03:03:16PM -0700, Zan Lynx wrote:
> > I have not checked if this is true, but it is a possible explanation:
> >
> > Perhaps the filesystem is not properly unmounted during a suspend? That
>
> Of course not.
>
> > would mean GRUB is reading from a incoherent filesystem on resume.
>
> Exactly.
>
> > GRUB's filesystem drivers are not very fancy. It could be it does
> > something silly like check the journal before returning each block.
>
> GRUB must not write to the fs, so it probably plays back the journal in
> memory only and it does this for every file it reads (at least that's how
> it feels :-)
>

Ah, OK, that makes sense. I did not expect GRUB to be *that* sophisticated :)

> > Maybe its a journal size thing, you could try "sync" before suspend and
> > see if it helps.
>
> We already sync inside the kernel, it does not help here, though.
> Blockdev freezing might help.
>

is there patch applicable to vanilla kernel? After repairing reiser several
times (due to hard lockups during suspend-to-RAM) that sounds even more
interesting.

> > Another thing would be to create /boot as a separate partition.
>
> Yes, that's what i always advise: /boot on separate ext2 partition. Then
> GRUB resumes fast.

well, this is small system, using yet another partition looked like useless
waste :)

thank you for explanation

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFWUD1R6LMutpd94wRAtWFAJ92STsDVby88UUWmNVK1q41X96RXgCeN6o4
ilUTLBdKZPsWPkWi5LOKsbg=
=U1xV
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/