On Thu, Jun 21, 2018 at 09:19:54PM -0600, Chris Murphy wrote: > On Thu, Jun 21, 2018 at 4:19 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > The mkfs ratios are about as optimal as we can get for the > > information we have about the storage - growing by > > 10x (i.e. increaseing the number of AGs by 10x) puts us at the > > outside edge of the acceptible filesystem performance and longevity > > charcteristics. Growing by 100x puts us way outside the window, > > and examples like this where we are taking about growing by 10000x > > is just way beyond anything the static AG layout architecture was > > ever intended to support.... > > OK that's useful information, thanks. > > What about from the other direction; is it possible to make an XFS > file system too big, on an LVM thin volume? That's harder, but still possible. e.g. to make a 40,000 AG filesystem using the mkfs defaults, we're talking about a *40PB* filesystem. That's going to hit limitations in dm-thinp long before XFs becomes a problem.... > For example a 1TB drive, and I'm scratching my head at mkfs.xfs time > and think maaaybe one day it could end up 25TB at the top end? That's within the realm of "should work fine, but is pushing the boundaries". > So I > figure do mkfs.xfs on a virtual LV of 5TB now and that gives me a 5x > growfs if I really do hit 25TB one day. But for now, it's a 5TB XFS > file system on a 1TB drive. Is there any negative performance effect > if it turns out I never end up growing this file system (it lives > forever on a 1TB drive as a 5TB virtual volume and file system)? There's no harm to XFS in doing this - this is the basic premise of handling thin provisioning space accounting at the filesystem level, and it's fundamental to my subvolume work. dm-thinp might have other ideas about how sane it is in the long term, however. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
