On Fri 10-02-12 02:52:17, Jamie Lokier wrote:

Alan Stern wrote:

quoted

On Wed, 1 Feb 2012, Pavel Machek wrote:

quoted

quoted

particular, this should help to solve a long-standing issue that, in
some cases, during resume from hibernation the boot loader causes the
journal to be replied for the filesystem containing the kernel image
and/or initrd causing it to become inconsistent with the information
stored in the hibernation image.

Ungood. Why is bootloader/initrd doing that? If it mounts filesystem
read/write, what is the guarantee that it will not change data on the
filesystem, breaking stuff?

Bootloaders should just not replay journals.

quoted

The user-space-driven hibernation (s2disk) is not covered by this
change, because the freezing of filesystems prevents s2disk from
accessing device special files it needs to do its job.

...so bootloaders need to be fixed, anyway.

I don't know about bootloaders, but from what I've heard, Linux fs
drivers (including those inside initrds) always replay the journal,
even if the filesystem is mounted read-only.  This could be considered
a bug in the filesystem code.

Theoretically a filesystem might need replay for the bootloader to see
a non-corrupt image, even for just the files it uses.

For example if the last state was in the middle of updating the root
directory, the /boot entry in the root directory might not be reliably
found without replaying the journal.

However replaying a journal when mounted read-only should probably
track journalled blocks in memory only, not commit back to the storage.

  Yes, that would be nice. Although memory constraints of the bootloader
might make it tricky.

  The reason why we don't have the functionality in kernel is not so much
about memory demands but more about the complexities of implementing the
caching - we'd have to create an equivalent of dm-snapshot of the device
from the mount code to trick generic code in pagecache to loading proper
replayed data).

								Honza
-- 
Jan Kara [off-list ref]
SUSE Labs, CR