On Mon, Feb 12, 2018 at 10:37 AM, Ellis H. Wilson III <ell...@panasas.com> wrote: > 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
When testing btrfs on large volumes, especially with metadata heavy operations, I'd suggest you match the node size of your mkfs.btrfs (-n) with the stripe size used in creating your RAID array. Also, use the ssd_spread mount option as discussed in a previous thread. It make a big difference on arrays. It allocates much more space for metadata, but it greatly reduces fragmentation over time. -- 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
