I was just looking into using overlayfs, and although it has some
promise, I think it's biggest drawback is the upperdir will have to be
some sort of storage backed filesystem. From my limited understanding of
tmpfs, it's not supposed to be the greatest with many large files (and
my system in particular would be downloading many large movies/videos,
and doing any kind of os update to test it would involve many changes
all over the volume, which could be problematic to commit to a golden
state.)
I could partition the main drive in 2 parts, and dynamically zero-out
then create the volume in the second partition on each boot, but I'm
still saving no drive writes, and not really extending the life of the
hardware (which is one of my premises.)
On 05/12/2014 11:12 PM, Chris Murphy wrote:
On Fri, Dec 5, 2014 at 11:27 AM, James West <james@xxxxxxxxxxxxxxxxxxx> wrote:
General idea would be to have a transient snapshot (optional quota support
possibility here) on top of a base snapshot (possibly readonly). On system
start/restart (whether clean or dirty), the transient snapshot would be
flushed, and the system would restart the snapshot, basically restarting
from the base snapshot.
Sounds similar to this idea:
http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
About 1/3 of the way down it gets to a proposal to Btrfs as a way to
get to a stateless system, which is basically what you want to be able
to rollback to. A variation on this that might serve the use case
better is seed device. You can either drop the added device that
stores changes to the seed device, or the volume (seed+added device)
can become another seed if you want to make the current state
persistent at next boot.
And still another possibility is overlayfs, which isn't Btrfs specific.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
