Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Aug 2016 10:05:16 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Eric McCorkle <eric@www.metricspace.net>
Cc:        hackers@freebsd.org
Subject:   Re: Info about suspend-to-disk
Message-ID:  <20160823070516.GI83214@kib.kiev.ua>
In-Reply-To: <141b1050-8fb5-e8c7-0e0f-50607f2f28b9@metricspace.net>
References:  <141b1050-8fb5-e8c7-0e0f-50607f2f28b9@metricspace.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 22, 2016 at 11:41:12PM -0400, Eric McCorkle wrote:
> Hi everyone,
> 
> I'm gathering information in preparation for possibly working on
> suspend-to-disk functionality.  I have a fairly good idea of what it
> would take and one way to attack it.  The overall plan would look
> something like this:
> 
> * Use dump functionality to write an entire OS image out to disk.  As
> this is a voluntary dump, it should be possible to go through the FS
> interface to produce a regular file.
And get fs state unsynchronized between on-disk state and the cached
state in memory at the moment where you begin dumping. Even if you
preallocate all storage for the dump file before taking kernel memory
snapshot, a write to the file may result in reallocation of the blocks
and incompatible changes in the inode block, at least.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160823070516.GI83214>