Alan Stern wrote: > On Wed, 1 Feb 2012, Pavel Machek wrote: > > > > 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. > > > > > 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. All the best, -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
