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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
