On Tue, Aug 25, 2020 at 07:40:15AM -0700, Darrick J. Wong wrote: > Zooming out a bit, maybe we should instead introduce a new "tuning" > parameter for -d and -r so that administrators could tune the filesystem > for specific purposes: > > -d tune=dax: Reject if device not dax, set daxinherit=1, set > extsize/su/sw to match PMD > > -d tune=ssd: Set agcount to match the number of CPUs if > possible, make the log larger to support a large number of > threads and iops. > > -d tune=rotational: Probably does nothing. ;) > > -d tune=auto: Query blkid to guess which of the above three > profiles we should use. > > -d tune=none: No tuning. > > And then you'd do the same for the realtime device. Please, no. The problem with this is that a specific "tune" will need to vary over time (e.g. when reflink is supported with DAX) and so now we back to the same situation where the definition of "tune=dax" changes depending on what version of mkfs you use. Hence you can still make a filesystem that the kernel won't mount because you have a xfsprogs that supports DAX+reflink and a kernel that doesn't. I just don't see this as a viable way to produce filesystems that work for specific situations because it doesn't solve the kernel vs xfsprogs version support issue that requires tweaking mkfs parameters manually to avoid... > This would help us get rid of the seeeekret mkfs wrapper that we use to > make it easier for our internal customers to use DAX since mkfs.xfs > doesn't support config files. Let's fix that, then. I've written a bunch of stuff in the past couple of years that uses basic ini config files via a simple library and it just works. If people are happy with ini format config files via a library, then I'll just go do that, eh? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
