Date: Thu, 07 Dec 2006 07:25:55 -0600 From: Eric Anderson <anderson@centtech.com> To: Ivan Voras <ivoras@fer.hr> Cc: freebsd-geom@freebsd.org Subject: Re: gsnapshot around ? Message-ID: <45781663.3060008@centtech.com> In-Reply-To: <4575EDEA.7020206@fer.hr> References: <20061201104955.GG9880@obiwan.tataz.chchile.org> <el1395$9lt$1@s ea.gmane.org> <4575E597.1030306@centtech.com> <4575EDEA.7020206@fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/05/06 16:08, Ivan Voras wrote: > Eric Anderson wrote: > >> I've been thinking a bit about this for a while. It would be a great >> tool to have, certainly. Does anyone have any particular >> implementation ideas? > > It's actually not that hard to do. I really want the possibility to save > snapshot data in a file (as opposed to dumping it to another GEOM > device), and PJD had some file-muching kernel code so it's definitely > doable right now. > > I'm still waiting on a "hot-plug" insertion of GEOM classes in between > two classes to make it really usable for the common man :) I've been thinking about a layered approach, so the gsnapshot would create a 'layer', and all new writes would go to the layer. Then, there would be another class, to stack layers (kind of like unionfs, except for block devices) - so when you wanted to view the data on a snapshot, you would stack the layers how you wanted, and then see the data. Kind of like journaling, kind of like regular COW, etc, but a little more Unix-style-ish in the manner of a few building blocks that can be used in many ways, and stacked together to make something powerful. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology An undefined problem has an infinite number of solutions. ------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45781663.3060008>