Re: [PATCH v5 2/5] fuse: make DAX mount option a tri-state

[Dave Chinner <david@fromorbit.com>]

On Thu, Sep 23, 2021 at 03:02:41PM -0400, Vivek Goyal wrote:
> On Thu, Sep 23, 2021 at 05:25:23PM +0800, Jeffle Xu wrote:
> > We add 'always', 'never', and 'inode' (default). '-o dax' continues to
> > operate the same which is equivalent to 'always'. To be consistemt with
> > ext4/xfs's tri-state mount option, when neither '-o dax' nor '-o dax='
> > option is specified, the default behaviour is equal to 'inode'.
> 
> So will "-o dax=inode" be used for per file DAX where dax mode comes
> from server?
> 
> I think we discussed this. It will be better to leave "-o dax=inode"
> alone. It should be used when we are reading dax status from file
> attr (like ext4 and xfs). 
> 
> And probably create separate option say "-o dax=server" where server
> specifies which inode should use dax.

That seems like a poor idea to me.

The server side already controls what the client side does by
controlling the inode attributes that the client side sees.  That
is, if the server is going to specify whether the client side data
access is going to use dax, then the server presents the client with
an inode that has the DAX attribute flag set on it.

In that case, turning off dax on the guest side should be
communicated to the fuse server so the server turns off the DAX flag
on the server side iff server side policy allows it.  When the guest
then purges it's local inode and reloads it from the server then it
will get an inode with the DAX flag set according to server side
policy.

Hence if the server side is configured with "dax=always" or
dax="never" semantics it means the client side inode flag state
cannot control DAX mode. That means, regardless of the client side
mount options, DAX is operating under always or never policy,
enforced by the server side by direct control of the client inode
DAX attribute flag. If dax=inode is in use on both sides, the the
server honours the requests of the client to set/clear the inode
flags and presents the inode flag according to the state the client
side has requested.

This policy state probably should be communicated to
the fuse client from the server at mount time so policy conflicts
can be be resolved at mount time (e.g. reject mount if policy
conflict occurs, default to guest overrides server or vice versa,
etc). This then means that that the client side mount policies will
default to server side policy when they set "dax=inode" but also
provide a local override for always or never local behaviour.

Hence, AFAICT, there is no need for a 'dax=server' option - this
seems to be exactly what 'dax=inode' behaviour means on the client
side - it behaves according to how the server side propagates the
DAX attribute to the client for each inode.

> Otherwise it will be very confusing. People familiar with "-o dax=inode"
> on ext4/xfs will expect file attr to work and that's not what we
> are implementing, IIUC.

The dax mount option behaviour is already confusing enough without
adding yet another weird, poorly documented, easily misunderstood
mode that behaves subtly different to existing modes.

Please try to make the virtiofs behaviour compatible with existing
modes - it's not that hard to make the client dax=inode behaviour be
controlled by the server side without any special client side mount
modes.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com