On Wed, Oct 17, 2018 at 12:42 PM Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > > > > On 10/13/18 11:05 AM, Ross Zwisler wrote: > > On Fri, Oct 12, 2018 at 2:21 AM Christoph Hellwig <hch@xxxxxx> wrote: > >> > >> On Thu, Oct 11, 2018 at 01:38:34PM -0500, Eric Sandeen wrote: > >>>> The different behavior between filesystems was confusing customers so > >>>> we had to align them, then the question was which default to pick. > >>>> Honestly, we came to the decision to bring ext4 in line with the xfs > >>>> behavior because we thought that would be easier than the alternative. > >>>> Dave and Christoph made repeated arguments that DAX is just a hidden > >>>> performance optimization that no application should rely on, so we > >>>> went the path of least resistance and changed the ext4 default. > >>> > >>> Ok, well, I guess we'd better reconcile "it's a hidden performance hint" > >>> with "if the administrator asked they must receive..." before making this > >>> change... cc: hch for bonus input. > >> > >> I don't really care too mouch on the mount options, the important bit > >> was the application behavior. > >> > >> I fully agree with Dan that we should have the same behavior for every > >> file system, though. > > > > One factor that might influence this is how we expect users to detect > > whether or not DAX is being used, and whether that can vary per-inode > > within a filesystem. If we choose to only have the mount option then > > I agree that a hard failure when -o dax doesn't work seems fine. And > > of course keeping the filesystems behaving the same is desirable. > > > > If we eventually do go back to having a per-inode DAX option, though, > > the mount option becomes a hint as to what the default behavior is, > > and the user will need another way to detect whether or not DAX is > > being used for a given inode. In that case having the mount option > > fail loudly isn't as important because all we've really changed is the > > filesystem's default, and the application will still need a consistent > > way of detecting whether the inode they are actually using is DAX or > > not. > > > > I'm not sure if per-inode DAX is still a goal for anyone. If not, > > then sure, using the DAX mount option as the one source of truth and > > making it a hard failure when it doesn't work seems reasonable. > > I've been thinking about the per-inode stuff a bit, and while I don't know > how to resolve some of the trickier issues, at least the expected behavior > seems like something we can narrow down and specify. > > Because it's an on-disk flag (in xfs today, in any case) it seems that > the only sane behavior to expect is either/or, i.e.: > > Mount option: All files always dax, per-inode flags ignored (or rejected) > Per-inode: Mount option cannot be specified; only inodes explicitly flagged are dax > > Think about it; what would mount-option-plus-per-inode mean? We have > no "negative" dax flag, so while mount-option-with-flag surely means > "dax", what the heck does mount-option-without-flag mean, and how is it > distinguishable from mount option only? > > I submit that flags can only have meaning w/o the fs-wide mount option > enabled, so the question of "should we hard fail mount -o dax for devices > that cannot support it" seems to be orthogonal to the per-inode question. > > i.e. mount -o dax really can only mean "I want dax on everything" and so > again, I think we probably need to fail the mount if that can't be honored. +1 from me. The mount option is a blunt global override and we should proceed with the finer-grained enabling. DAX is not guaranteed to have neutral to positive performance impact so it should be enabled consciously.
