Re: [RFC 0/2] New MAP_PMEM_AWARE mmap flag

[Jeff Moyer <jmoyer@redhat.com>]

Dan Williams <dan.j.williams@intel.com> writes:

> In general MAP_SYNC, makes more sense semantic sense in that the
> filesystem knows that the application is not going to be calling *sync

and so it makes sure its metadata is consistent after a write fault.

What you wrote is true for both MAP_SYNC and MAP_PMEM_AWARE.  :)

I assume you meant that MAP_SYNC is semantically cleaner from the file
system developer's point of view, yes?  Boaz, it might be helpful for
you to write down how an application might be structured to make use of
MAP_PMEM_AWARE.  Up to this point, I've been assuming you'd call it
whenever an application would call pcommit (or whatever the incantation
is on current CPUs).

> Although if we had MAP_SYNC today we'd still be in the situation that
> an app that fails to do its own cache flushes / bypass correctly gets
> to keep the broken pieces.

Dan, we already have this problem with existing storage and existing
interfaces.  Nothing changes with dax.

> The crux of the problem, in my opinion, is that we're asking for an "I
> know what I'm doing" flag, and I expect that's an impossible statement
> for a filesystem to trust generically.

The file system already trusts that.  If an application doesn't use
fsync properly, guess what, it will break.  This line of reasoning
doesn't make any sense to me.

> If you can get MAP_PMEM_AWARE in, great, but I'm more and more of the
> opinion that the "I know what I'm doing" interface should be something
> separate from today's trusted filesystems.

Just so I understand you, MAP_PMEM_AWARE isn't the "I know what I'm
doing" interface, right?

It sounds like we're a long way off from anything like MAP_SYNC going
in.  What I think would be useful at this stage is to come up with a
programming model we can all agree on.  ;-)  Crucially, I want to avoid
the O_DIRECT quagmire of different file systems behaving differently,
and having no way to actually query what behavior you're going to get.

Cheers,
Jeff

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>