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.


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

Reply via email to