Date: Tue, 23 Aug 2016 12:48:00 +0200 From: Torsten Zuehlsdorff <mailinglists@toco-domains.de> To: Eric McCorkle <eric@metricspace.net>, hackers@freebsd.org Subject: Re: Info about suspend-to-disk Message-ID: <9a1f190c-9d43-cb8f-ab85-a0caa132a4e6@toco-domains.de> 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 23.08.2016 05:41, 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. > > * Modify boot1 to check for saved images. Load and resume if one exists. > > * Presumably there would need to be some new device methods added to do > saving/reinitialization of devices. > > > The major open questions for me are the following: > > * Is there/has there been significant work in this direction? > > * Is there perhaps a better strategy? > > * Do the codepaths currently exist to allow dump functionality to write > to a regular file in the case of a voluntary dump, or would this need to > be added? > > * What would be the most sensible default behavior for device > hibernate/unhibernate methods? > > * Any other significant issues What about encryption? I used encryption and ZFS - how should this work? ;) Greetings, Torsten
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9a1f190c-9d43-cb8f-ab85-a0caa132a4e6>