[Gluster-users] Bricks as BTRFS

[James]

On Fri, Sep 26, 2014 at 5:57 PM, Ric Wheeler <rwheeler at redhat.com> wrote:
> reflink for backup is really a bad idea since you will not have really made
> a second copy - if the disk fails (even partially!) you might lose data
> since we will not have a second copy of the blocks. Where it is not
> supported, you will still need to do a full file copy which means normal
> file operation speed for the backup and restore.


Perhaps I didn't express the feature well enough, but here is what I
think would be particularly useful, and how the reflink operation can
make this extremely powerful. The below description works for the
single server use case, but does not (AFAICT) yet exist for the multi
machine Gluster scenario.

When running an incremental backup with something like rsnapshot, only
changed files are copied. Therefore in this common scenario you
actually only have one copy of each current file, and each file that
is the same across snapshots is in fact a hardlink to the same data.

To do a restore, the operation could take hours, days, or even longer
depending on how much data is present. If you cp --reflink, then you
effectively complete the copy to restore location instantly (since the
blocks don't need to be duplicated) and as they are COW files, changes
happen as needed, without affecting the backup.

Similarly, with a backup operation, many TB of data can be copied very
quickly, because the data blocks don't need to move.

The only problem with this scheme is that it only works for the single
machine use case. Distributing it and replicating it across a scalable
system like GlusterFS would extend this scheme to large data sets. I
don't know how feasible that is, but I have been led to believe that
it is.

Hopefully the above use case is a compelling one. Any sysadmin who has
sat and watched their data restore for 3 days knows the value of it.

Cheers,
James