(sorry if my Message-ID header is missing, I am not subscribed to the mailing
list,
so I reply using mail-archive)
> So a workaround would be reducing your duperemove usage and possibly
> rewriting (for instance via defrag) the deduped files to kill the
> multiple reflinks. Or simply delete the additional reflinked copies, if
> your use-case allows it.
Sadly, I need the extra space (that's why I was using duperemove in the first
place)
and can not delete all duped copies. These are mainly several checkouts of
different repositories
with partially common (partially large binary) content.
> And thin down your snapshot retention if you have many snapshots per
> subvolume. With the geometric scaling issues, thinning to under 300 per
> subvolume should be quite reasonable in nearly all circumstances, and
> thinning to under 100 per subvolume may be possible and should result in
> dramatically reduced scaling issues.
In addition, I have only ~ 5 snapshots for both those volumes, which should
certainly not be too much.
So in short, this just means btrfs send is (still) unusable
for filesystems which rely on the offline dedupe feature (in the past 'btrfs
send' got broken
after dedupe which got fixed, now it is just extremely slow).
For me, this means I have to stay with rsync backups, which are sadly
incomplete since special FS attrs
like "C" for nocow are not backed up.
Cheers and thanks for your reply,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
