Re: [zfs-discuss] send/receive statistics
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] send/receive statistics
[EMAIL PROTECTED] 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/listinfo/zfs-discuss > > ___ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] send/receive statistics
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/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] send/receive statistics
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
