zfs discuss - Feb 2011 - Question regarding "zfs snapshot -r" and also regarding "zfs send -R"

Hello Eric,

Thanks for your response. I have another question. This time regarding zfs
send. I have updated the subject line to include "zfs send" question
in this
thread.


If the pool tank has 5000 descendent file systems and the snapshots are
being taken using "zfs snapshot -r". Now I will be sending and
receiving
incremental snapshot to a second system using the following command.

"zfs send -R -i <prev snapshot> <latest snapshot> | ssh
<second_sysname> zfs
recv -vFd tank"

My question is:

Is "zfs send -R " sends snapshot all at once OR  does it send all the
descendent snapshots serially(one after another) ?

I am asking this because, if it sends serially, send/recv will take long
time to finish based on the number of snapshots need to be send and this
duration will gradually increase if number of snapshots also keep
increasing. Is my assumption correct?

Thanks,

-- Rahul

On Tue, Feb 1, 2011 at 5:05 PM, Eric D. Mudama <edmudama at
bounceswoosh.org>wrote:
> On Tue, Feb  1 at 10:54, Rahul Deb wrote:
>
>>  Hello All,
>>  I have two questions related to "zfs snapshot -r"
>>  1. When "zfs snapshot -r tank at today" command is issued,
does it creates
>>  snapshots for all the?descendent file systems at the same moment? I
mean
>>  to say if the command is issued at 10:20:35 PM, does the creation time
of
>>  all the snapshots for descendent file systems are same?
>>  2. Say, tank has around 5000 descendent file systems and "zfs
snapshot -r
>>  tank at today" takes around 10 seconds to complete. If there is a
new file
>>  systems created under tank within that 10 seconds period, does that
>>  snapshot process includes the new file system created within that 10
>>  seconds?
>>  OR it will exclude that newly created filesystem?
>>  Thanks,
>>  -- Rahul
>>
>
> I believe the contract is that the content of all recursive snapshots
> are consistent with the instant in time at which the snapshot command
> was executed.
>
> Quoting from the ZFS Administration Guide:
>
>  Recursive ZFS snapshots are created quickly as one atomic
>  operation. The snapshots are created together (all at once) or not
>  created at all. The benefit of such an operation is that the snapshot
>  data is always taken at one consistent time, even across descendent
>  file systems.
>
> Therefore, in #2 above, the snapshot wouldn''t include the new file
in
> the descendent file system, because it was created after the moment in
> time when the snapshot was initiated.
>
> In #1 above, I would guess the snapshot time is the time of the
> initial command across all filesystems in the tree, even if it takes
> 10 seconds to actually complete the command.  However, I have no such
> system where I can prove this guess as correct or not.
>
> --eric
>
> --
> Eric D. Mudama
> edmudama at mail.bounceswoosh.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110202/47aa3fd7/attachment.html>

On Wed, Feb  2 at 17:03, Rahul Deb wrote:
> Is "zfs send -R " sends snapshot all at once OR does it send all
> the descendent snapshots serially(one after another) ?  I am
> asking this because, if it sends serially, send/recv will take
> long time to finish based on the number of snapshots need to be
> send and this duration will gradually increase if number of
> snapshots also keep increasing. Is my assumption correct?
> Thanks,
> -- Rahul
We do not use send|recv for descendent filesystems, so I don''t have
personal experience, but I am pretty sure the send is an
all-or-nothing operation which runs serially.  Our setup sustains
about 40MB/s on our send|recv using SSL to a backup server with
1500MTU, so I don''t think we''re doing that poorly.  Our 40MB/s
is
measured with the system under concurrent server load, so I don''t
think it''s doing that poorly.

Parallelization of the send|recv would only net a benefit if a serial
approach was unable to saturate the network interface, but I''ve yet to
witness that case.  Some setups will forgo ssl and instead use one of
the network pipe interfaces that isn''t encrypted, which can improve
performance when CPU bound, but we haven''t tried to setup anything
like that since we haven''t needed it.

Using -R by itself will result in a larger send|recv each time, as you
suspect, unless you also use -I/-i to do incrementals.  In the -I/-i
case, the size of the incremental is relative to the amount of new
data since the last time you sent incrementals, similar to rsync or a
half dozen other techniques.

At work we always use -i, and our send|recv is anywhere from 5-20
minutes, depending on what data was added or modified.

--eric

-- 
Eric D. Mudama
edmudama at bounceswoosh.org