Re: [PATCH 0/6] xfsprogs: blockdev dax detection and warnings

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com