Re: Mounting xfs filesystem takes long time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 28, 2018 at 12:05:04PM +1000, Dave Chinner wrote:
> On Wed, Jun 27, 2018 at 06:37:31PM -0500, Eric Sandeen wrote:
> > 
> > 
> > On 6/27/18 6:23 PM, Luis R. Rodriguez wrote:
> > > On Fri, Jun 22, 2018 at 02:02:21PM +1000, Dave Chinner wrote:
> > >> 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....
> > > 
> > > I don't  have time to test this but I can probably do so after my vacation
> > > (now). Would it be best to just codify this eventually instead of having
> > > this as tribal knowledge?
> > 
> > Honestly, if we wanted something like this I think it'd be based on terminal
> > AG count, not growfs multiplier for a specific instance.
> 

Agreed. The biggest issue here is the amount of AGs, not the filesystem size
directly, which, for this to work in a reliable way, we'd need to store the
'original' AG count from when the FS was created, otherwise, as Eric stated,
nothing prevents somebody to use growfs several times, instead of growing the FS
in a single time.

Although, this makes me wonder if we somehow couldn't make it a bit more
flexible in the future, but I think that's where Dave's subvolume work comes in?


> IMO, this belongs in the admin documentation (e.g. the growfs man
> page), not the code. The people writing apps and automated
> deployment scripts that grow filesystems need to know about this,
> not the end users who simply use these pre-canned
> apps/environments...
> 

+1, most people who will look into the code already know this, users of grow FS
doesn't, so this belongs to the man page IMHO.

> 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

-- 
Carlos
--
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



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux