Hello all,
Any plans (or already have), a send/receive way to get the transfer backup statistics? I mean, the "how much" was transfered, time and/or bytes/sec?
And the last question... i did see in many threads the question about "the consistency between the send/receive through ssh"... but no definitive answers.
So, my last question is: If the transfer is completed (send/receive), i can trust the backup was good. The "receive" returning "0" is definitive?

Thanks.
--
This message posted from opensolaris.org

Marcelo Leal wrote:
> Hello all,
> Any plans (or already have), a send/receive way to get the transfer backup statistics? I mean, the "how much" was transfered, time and/or bytes/sec?
>

I'm not aware of any plans, you should file an RFE.

> And the last question... i did see in many threads the question about "the consistency between the send/receive through ssh"... but no definitive answers.
>

There is no additional data protection on the stream. The data is verified
by the receive. But if you redirect the stream to a file, for instance, and
then later attempt the receive and encounter checksum errors, then you
might be sad. In other words, the end-to-end verification of send streams
exists, but there is no inherent data protection in the stream. The use of
ssh tends to work well, because secure protocols also check the integrity
of the data flowing between machines and will retry.

> So, my last question is: If the transfer is completed (send/receive), i can trust the backup was good. The "receive" returning "0" is definitive?
>

If the receive completes without error, then everything passed the
checksum verification.
-- richard

On 4-Sep-08, at 4:52 PM, Richard Elling wrote:

> Marcelo Leal wrote:
>> Hello all,
>> Any plans (or already have), a send/receive way to get the
>> transfer backup statistics? I mean, the "how much" was transfered,
>> time and/or bytes/sec?
>>
>
> I'm not aware of any plans, you should file an RFE.
>
>> And the last question... i did see in many threads the question
>> about "the consistency between the send/receive through ssh"...
>> but no definitive answers.
>>
>
> There is no additional data protection on the stream. The data is
> verified
> by the receive. But if you redirect the stream to a file, for
> instance, and
> then later attempt the receive and encounter checksum errors, then you
> might be sad. In other words, the end-to-end verification of send
> streams
> exists, but there is no inherent data protection in the stream.
> The use of
> ssh tends to work well, because secure protocols also check the
> integrity
> of the data flowing between machines and will retry.

What about the idea mooted recently here of 'zfs send' presenting a
final checksum which could be checked by receiver? (Where destination
is not 'zfs receive'). Worth doing?

--Toby

>
>> So, my last question is: If the transfer is completed (send/
>> receive), i can trust the backup was good. The "receive" returning
>> "0" is definitive?
>>
>
> If the receive completes without error, then everything passed the
> checksum verification.
> -- richard
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/...fo/zfs-discuss

zfs-discuss-bounces@opensolaris.org wrote on 09/04/2008 03:40:46 PM:

>
> On 4-Sep-08, at 4:52 PM, Richard Elling wrote:
>
> > Marcelo Leal wrote:
> >> Hello all,
> >> Any plans (or already have), a send/receive way to get the
> >> transfer backup statistics? I mean, the "how much" was transfered,
> >> time and/or bytes/sec?
> >>
> >
> > I'm not aware of any plans, you should file an RFE.
> >
> >> And the last question... i did see in many threads the question
> >> about "the consistency between the send/receive through ssh"...
> >> but no definitive answers.
> >>
> >
> > There is no additional data protection on the stream. The data is
> > verified
> > by the receive. But if you redirect the stream to a file, for
> > instance, and
> > then later attempt the receive and encounter checksum errors, then you
> > might be sad. In other words, the end-to-end verification of send
> > streams
> > exists, but there is no inherent data protection in the stream.
> > The use of
> > ssh tends to work well, because secure protocols also check the
> > integrity
> > of the data flowing between machines and will retry.
>
> What about the idea mooted recently here of 'zfs send' presenting a
> final checksum which could be checked by receiver? (Where destination
> is not 'zfs receive'). Worth doing?
>
> --Toby

I don't have time to dig in the zfs send/receive code right now but I don't
understand why, if the checksums for the delta blocks exist on the sending
side, the receiving side does not write and verify the checksum matches.
Tossing a error or just plain exit or reverting to the base snapshot of the
receive (based on options) when a block checksum does not match while
receiving? I understand send and receive were created to be pipeable --
but why should that exclude error handling?

-Wade

>
> >
> >> So, my last question is: If the transfer is completed (send/
> >> receive), i can trust the backup was good. The "receive" returning
> >> "0" is definitive?
> >>
> >
> > If the receive completes without error, then everything passed the
> > checksum verification.
> > -- richard
> >
> > _______________________________________________
> > zfs-discuss mailing list
> > zfs-discuss@opensolaris.org
> > http://mail.opensolaris.org/mailman/...fo/zfs-discuss
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/...fo/zfs-discuss

Thanks a lot for the answers!
Relling did say something about checksum, i did ask to him about a more "detailed" explanation about it. Because i did not understand "what" checksum the receive part has to check, as the send can be redirected to a file on a disc or tape...
In the end, i think if we can import (receive) the snapshot, and that procedure ends fine, we are in good shape.
Leal.
--
This message posted from opensolaris.org