On 02/11/2018 01:24 PM, Hans van Kranenburg wrote:
Why not just use `btrfs fi du <subvol> <snap1> <snap2>` now and then and
update your administration with the results? .. Instead of putting the
burden of keeping track of all administration during every tiny change
all day long?
I will look into that if using built-in group capacity functionality
proves to be truly untenable. Thanks!
CoW is still valuable for us as we're shooting to support on the order
of hundreds of snapshots per subvolume,
Hundreds will get you into trouble even without qgroups.
I should have been more specific. We are looking to use up to a few
dozen snapshots per subvolume, but will have many (tens to hundreds of)
discrete subvolumes (each with up to a few dozen snapshots) in a BTRFS
filesystem. If I have it wrong and the scalability issues in BTRFS do
not solely apply to subvolumes and their snapshot counts, please let me
know.
I will note you focused on my tiny desktop filesystem when making some
of your previous comments -- this is why I didn't want to share specific
details. Our filesystem will be RAID0 with six large HDDs (12TB each).
Reliability concerns do not apply to our situation for technical
reasons, but if there are capacity scaling issues with BTRFS I should be
made aware of, I'd be glad to hear them. I have not seen any in
technical documentation of such a limit, and experiments so far on 6x6TB
arrays has not shown any performance problems, so I'm inclined to
believe the only scaling issue exists with reflinks. Correct me if I'm
wrong.
Thanks,
ellis
--
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
