On Fri, Jun 30, 2017 at 10:33:03AM +0200, Alphazo wrote:

Hello,

xfs never stops impressing me. Most if not all of my storage has been
converted to it, including a 30TB+ unRaid server. I have been
contemplating snapshot and dedup enabled filesystems like btrfs and
ZFS but couldn't justify the jump. The new xfs reflink feature seems a
good addition and compromise to a stable and proven filesystem.
I'm strongly considering using the experimental reflink feature for my
new photo drive.

FWIW, reflink is still an experimental feature and not production ready,
so beware that it could eat your backups...

This will be done in a controlled environment with multiple backups.

...so good to hear this.  Note that the copy-on-write side of reflink
can fragment files and filesystems more heavily than 

Are there any general rules of conduct when working with a dedup
filesystem, like never go above 80% disk usage

That's a pretty good rule of thumb for a filesystem regardless of
whether it supports reflink. :)

That said, we do try to reserve space for future metadata expansion
to avoid running out of space and crashing the fs.

or never trust df/dh results?

The free counts should be accurate, space reservations notwithstanding.

Also is there any risk of trying to mount a reflink enabled xfs
filesystem on an older kernel that doesn't know about it?

No, we set a feature flag bit for reflink (and rmap) so that old
kernels will not try to write to an fs they don't understand.

I don't think I need it for the moment but would enabling rmapbt as
well add any risk to the data integrity

It shouldn't.

or impact performance?

It will, on account of having to update the rmap metadata.

Can rmapbt be enabled later on an existing filesystem if required?

No.

Will rmpabt be only used to enhance filesystem recovery?

It may some day be used to implement online shrink, but for now the only
things that /could/ use it are xfs_repair and online fsck.

I'm planning to use this reflink feature for instant local snapshots
and then use my backup software of choice, borg, to keep a long time
history of my work on a remote server. Since borg stores data in a
dedup fashion I can also backup the reflink snapshots and they won't
take additional space. The only drawback is that today borg need to
hash all the files found in a reflink directory in order to find out
about dedup blocks. I asked a question on the borg mailing list
https://github.com/borgbackup/borg/issues/2743 and apparently it won't
be an issue to add a feature to support XFS in order to identify the
physical extents. Is rmapbt required for that?

borgbackup will probably need to call the GETFSMAP ioctl, which won't
land until 4.12.  On xfs, rmapbt is needed to supply data block
ownership info, which is what borgbackup (and bees, and...) say they
want to be smarter about dedup.

Good luck!

--D

Alphazo
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html