public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Valdis.Kletnieks@vt.edu (Valdis.Kletnieks at vt.edu)
To: linux-arm-kernel@lists.infradead.org
Subject: [INFO] : Hibernation and Resume between 2 similar devices
Date: Wed, 14 Mar 2012 13:33:05 -0400	[thread overview]
Message-ID: <10238.1331746385@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Wed, 14 Mar 2012 03:21:58 PDT." <1331720518.14716.YahooMailNeo@web162005.mail.bf1.yahoo.com>

On Wed, 14 Mar 2012 03:21:58 PDT, PINTU KUMAR said:
> > From: Rafael J. Wysocki <rjw@sisk.pl>
> > Not out of the box (you'd need to hack the kernel for that to work I think,
> > at least on x86) and the devices would need to be _exactly_ identical.
> > Moreover, if there is read-write mass storage in them, the filesystems on
> > both would have to be exactly identical as well (including metadata and data
> > layout etc.).

> Suppose in "Device 1" during hibernation, I have a file say "file1.txt" opened whose inode number is say "123456".
> This opened state of file1.txt will be captured in hibernation image.
> Now assume that same "file1.txt" is also present (not opened) in "Device2" but whose inode number is say "567890".
> Now if I reboot "Device 2" and try to resume from hibernated image of "Device 1", what would happen to "file1.txt" ??

Rafael was quite clear - the mass storage has to be *identical*.  You reboot
with the image of "Device 1", that had file1.txt open, what will happen when
you close (or write, or sync) the file is this:

1) You'll write data out to disk into whatever blocks were owned by inode
12345, no matter who actually owns them on Device2's storage.

2) You'll write out inode 12345 to disk, no matter what used to be there.

Note that you'll do this same thing for *every single* file that was open when
you hibernated, which means you'll corrupt every file that was opened *and*
every file that was closed but was using the same blocks on the new disk as the
open file was using on the original disk.

In short, you just completely corrupted the file system. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120314/aa61ef05/attachment.sig>

  reply	other threads:[~2012-03-14 17:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-13  4:53 [INFO] : Hibernation and Resume between 2 similar devices PINTU KUMAR
2012-03-13 20:36 ` Rafael J. Wysocki
2012-03-14 10:21   ` PINTU KUMAR
2012-03-14 17:33     ` Valdis.Kletnieks at vt.edu [this message]
2012-03-15 14:53       ` PINTU KUMAR

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=10238.1331746385@turing-police.cc.vt.edu \
    --to=valdis.kletnieks@vt.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox