From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.jrs-s.net ([173.230.137.22]:59089 "EHLO mail.jrs-s.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753321AbaHKSIM (ORCPT ); Mon, 11 Aug 2014 14:08:12 -0400 Message-ID: <53E9068B.3090005@jrs-s.net> Date: Mon, 11 Aug 2014 14:08:11 -0400 From: Jim Salter MIME-Version: 1.0 To: Ames Cornish CC: Ames Cornish , linux-btrfs@vger.kernel.org Subject: Re: Announcement: buttersink - like rsync for btrfs snapshots References: <53E90409.5050105@jrs-s.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: To any core btrfs devs who are listening and care - the unreliability of btrfs send/receive is IMO the single biggest roadblock to adoption of btrfs as a serious next-gen FS. I can live with occasional corner-case performance issues, I can even live with (very) occasional filesystem corruption... IF I can rely on replication to keep my data safe on another box. Without the replication, there's just no reasonable case to be made to replace ZFS. On 08/11/2014 02:05 PM, Ames Cornish wrote: > Jim, > > btrfs send reliability has been an issue, though I've been able to > successfully use it for my backups. buttersink usually detects the > errors and will either move the destination snapshot to mark it as > partial/failed (for btrfs), or cancel and delete the partial upload > (for S3). I've also found that it helps to wait a while (e.g. 30 > seconds) after any volume deletes before trying the send/sync. I hope > btrfs-progs will get more reliable, too. > > - Ames