On Mon, Apr 18, 2016 at 2:19 PM, Greg Freemyer
No, it's a partial system shutdown followed by a hibernate. The shutdown kills all apps, but leaves the NTFS volumes dirty.
I'm not sure if it's dirty in the same way as an unclean unmount, or if it's a separate flag that indicates a hibernation file is in play. It could set both dirty and hibernate flags, that'd make sense also. Seems like it'd be a bad idea to hibernate without at least syncing the system so that it can easily recover from merely journal replay at next mount in case the hibernation file croaks. The problem that remains is if the volume were to be mounted elsewhere and modified, and then the hibernation image resumed. In that case there'd be a disconnect between the two states. And maybe that's what the "hibernate" form of dirty flag helps avoid? It doesn't seem we have such a thing on Linux file systems. If Linux A hibernates, and Linux B is booted, say a Live USB stick or even dual boot where another bootloader assumes control before (software) hibernation can be resumed, and Linux A's volume were mounted and modified, what happens when Linux A is rebooted? Can the kernel know there's a difference in the file system states? The on disk state is clearly different than the state known by the hibernation file. And if yes does the kernel fail to resume from hibernate, discard/invalidate the hibernation file, and fallback to normal boot? Or does it proceed? If it proceeds to resume and mounts the file system, I expect eventual and significant corruption. And if that's true whose problem is this (component wise, obviously it's ultimately the user's problem, even though not their fault)? -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org