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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200611140707.17935.arvidjaar@mail.ru>
Date:	Tue, 14 Nov 2006 07:07:13 +0300
From:	Andrey Borzenkov <arvidjaar@...l.ru>
To:	Stefan Seyfried <seife@...e.de>
Cc:	Zan Lynx <zlynx@....org>, linux-kernel@...r.kernel.org,
	Pavel Machek <pavel@....cz>
Subject: Re: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

-----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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/