Date: Wed, 3 Jul 2013 01:34:36 -0500 From: Kevin Day <toasty@dragondata.com> To: Jeremy Chadwick <jdc@koitsu.org> Cc: freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: EBS snapshot backups from a FreeBSD zfs file system: zpool freeze? Message-ID: <6488DECC-2455-4E92-B432-C39490D18484@dragondata.com> In-Reply-To: <20130703055047.GA54853@icarus.home.lan> References: <87li5o5tz2.wl%berend@pobox.com> <CA%2BtpaK1jQuKneQsxkVfxJGzXdPdLZfqBM1QWQ0e19nK5t71t1Q@mail.gmail.com> <87ehbg5raq.wl%berend@pobox.com> <20130703055047.GA54853@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Jul 3, 2013, at 12:50 AM, Jeremy Chadwick <jdc@koitsu.org> wrote:
> On Wed, Jul 03, 2013 at 02:08:13PM +1200, Berend de Boer wrote:
>>
>> For starters, I suppose very few people are using FreeBSD on AWS, so
>> "most of us" don't have a choice :-)
>>
>> But this might simply be my understanding: what if I want to use the
>> EBS snapshot of the 5 disks I've taken and attach them to another
>> machine, and mount it?
>>
>> But perhaps you don't know what an EBS snapshot is? It's not a backup
>> of your file system, it's a hardware-based backup of a disk at a
>> single point in time.
>>
>> I.e. with EBS I can take a snapshot of 5 1TB, create new disks from
>> it, and attach it to another machine. In SECONDS.
>
> Okay, I think I understand what you're asking. Please correct me:
>
> It sounds to me like the Linux OS images on AWS have utilities or the
> capability to create EBS images that are snapshots of the "virtual
> disks" that make up the AWS system, and that you can transfer these
> to another Linux AWS machine and mount the EBS images, and that this is
> being done within Linux itself.
>
> Correct?
>
> If so -- then what you're wanting to ask is: "does FreeBSD have support
> for EBS images?" (Meaning this has nothing to do with ZFS) I get the
> impression an EBS image is a proprietary Amazon thing, so you would need
> to ask Amazon if they have the same utilities for FreeBSD, or ask the
> individual(s) responsible for the FreeBSD AWS images if there are such
> tools. Again: nothing to do with ZFS.
Not quite, we run into something similar with VMware ESXi, so let me try to rephrase it.
ESXi provides block storage to virtual machines that appear to be traditional disks. ESXi has no real knowledge of the contents, files, it's just dumb block storage. This is like EBS, the volumes appear to be normal disks to the virtual machine.
But, the backend storage system allows you to take snapshots of the virtual disks. You can then roll back to an earlier snapshot, or make copies of the snapshots for other VMs to use. The problem is that unless you quiesce the filesystem before making the snapshot, the contents are potentially "dirty". It could be mid-write, or in the middle of doing something that would be bad to leave that way. If you're unlucky and make a snapshot during one of those inconsistent periods, if you were to rollback or clone that snapshot you'd get fsck complaining (for UFS) or ZFS may need to do some repairing, etc. This is much less an issue with ZFS than other filesystems, but it's still possible to think you've written something, try to trigger a snapshot, and it's not actually committed to disk yet.
Linux has an ioctl(?) you can call that says "Quiesce this filesystem", where all dirty buffers are flushed and (i believe), writes are blocked, and the filesystem is temporarily marked clean. You then trigger the backend storage to make a filesystem, then you unfreeze the filesystem so that normal I/O can continue.
The closest thing we can do in FreeBSD is to unmount the filesystem, take the snapshot, and remount. This has the side effect of closing all open files, so it's not really an alternative.
The other option is to not freeze the filesystem before taking the snapshot, but again you risk leaving things in an inconsistent state, and/or the last few writes you think you made didn't actually get committed to disk yet. For automated systems that create then clone filesystems for new VMs, this can be a big problem. At best, you're going to get a warning that the filesystem wasn't cleanly unmounted.
[-- Attachment #2 --]
0 *H
01 0 + 0 *H
/00Šq_Mtq40
*H
0{1 0 UGB10U Greater Manchester10U Salford10U
Comodo CA Limited1!0 U AAA Certificate Services0
040101000000Z
281231235959Z01 0 UUS1 0 UUT10USalt Lake City1 0 U
The USERTRUST Network1!0 U http://www.usertrust.com1604U-UTN-USERFirst-Client Authentication and Email0"0
*H
0
9}A;bF7`u9eJGHjM5BI/ |1Nd.)բdąQ5yNh{ zɤ2 O0 nFxoY^/m/묡j.g5y iF͠ v:z'[=s "HaLi.1 ,CZ qYں
gT:
we tbh ~GeMW(t40b0, '0#0 U #0
#>)00 U g}ĝ&p KPH|=n}0U 0U 00 U %0++0U
00U 0{U t0r08642http://crl.comodoca.com/AAACertificateServices.crl06420http://crl.comodo.net/AAACertificateServices.crl0 `HB0
*H
<~ v9<O ૄ]Te;m |7,%T_!7OT klE`-QLf<J?VvÂOl atG@We"'gOWdZٍ /i)J /LQFĊ7N 1hǞċ~2hD*Q`Mt:C29V:RAC3'9N&9≸])&A곛wuʵeJc>D^s 00mOj3""2zq0
*H
01 0 UUS1 0 UUT10USalt Lake City1 0 U
The USERTRUST Network1!0 U http://www.usertrust.com1604U-UTN-USERFirst-Client Authentication and Email0
110428000000Z
200530104838Z01 0 UGB10UGreater Manchester10USalford10U
COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA0"0
*H
0
[KW^/@ȣSX_fe2N2}UxLUB'qi2@'Vbqi c^`ʢAj HmeC*.+c8w߱ڂ2jgo \5Tq
7
PSl Y1 LR@[HhJ$ :q_㬿;%qh=XF<hmz!W42~JRrd&N`ohQcB}"cөΞD\[5 K0G0 U #0g}ĝ&p KPH|=n}0 U zN t[xcd'/[y{0U 0U 0 0U
00U 0XU Q0O0MKIGhttp://crl.usertrust.com/UTN-USERFirst-ClientAuthenticationandEmail.crl0t+h0f0=+01http://crt.usertrust.com/UTNAddTrustClient_CA.crt0%+0http://ocsp.usertrust.com0
*H
־xWUm3DRB
JAIZҭsn>&|L0(B<%>
u=9fѡMo(l tZڱuz/y VtCr`9 G:eH<=%`I?C
3_н`j;:< I3B)93i.EMiڀ =]|Gm]W0KID~y83:]&XaU!ՙC@B0Ұun0,0 7Ca`)̀0
*H
01 0 UGB10UGreater Manchester10USalford10U
COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA0
130616000000Z
140616235959Z0&1$0" *H
toasty@dragondata.com0"0
*H
0
-`ghX/9+ˈe`?l/ E^~T׀/q+5SzSrIuert`:"k_s{&
0T
kˢbW ieK;2 LX8w.YpI!3|M19 Y2vGrA ҽ5yX^0
@JbfBќ`
T ZO$mx1}LN0Rw 00 U #0zN t[xcd'/[y{0 U p =#P}L:wqX0U 0 U 0 0 U %0+ +10 `HB 0FU ?0=0; +10+0)+ https://secure.comodo.net/CPS0WU P0N0LJHFhttp://crl.comodoca.com/COMODOClientAuthenticationandSecureEmailCA.crl0+|0z0R+0Fhttp://crt.comodoca.com/COMODOClientAuthenticationandSecureEmailCA.crt0$+0http://ocsp.comodoca.com0 U 0toasty@dragondata.com0
*H
i qk4Dlse-8 uy:1:ߩ( w}tRƼHyT 4Y=GeKr:/ܜ1n*tښ6ڇڿ3D.~fm5Q(Yœ!@'=vn5i뷹 K^#MF0=~<h GgһKR}KrBai1cvqm3RNSeEx\G4
=FwɺL4rI U10001 0 UGB10UGreater Manchester10USalford10U
COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA 7Ca`)̀0 + 0 *H
1 *H
0 *H
1
130703063437Z0# *H
1|v{3ZP=! j0 +71001 0 UGB10UGreater Manchester10USalford10U
COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA 7Ca`)̀0 *H
101 0 UGB10UGreater Manchester10USalford10U
COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA 7Ca`)̀0
*H
灿^<W ~
%!~U 40AFf"
\6vdIAU/En~\$tRZQ߳S$;vP%ECڑ;347mT2!h5E ujcC!lz-^Tw)eTﺧЫ@H)~d>/<BlXzrFyV )TZ@ w)PIZ?o.WR A@.\,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6488DECC-2455-4E92-B432-C39490D18484>