Hello, Dan-san,
On 2021/02/27 4:24, Dan Williams wrote:
On Fri, Feb 26, 2021 at 11:05 AM Darrick J. Wong <djwong@xxxxxxxxxx> wrote:
On Fri, Feb 26, 2021 at 09:45:45AM +0000, ruansy.fnst@xxxxxxxxxxx wrote:
Hi, guys
Beside this patchset, I'd like to confirm something about the
"EXPERIMENTAL" tag for dax in XFS.
In XFS, the "EXPERIMENTAL" tag, which is reported in waring message
when we mount a pmem device with dax option, has been existed for a
while. It's a bit annoying when using fsdax feature. So, my initial
intention was to remove this tag. And I started to find out and solve
the problems which prevent it from being removed.
As is talked before, there are 3 main problems. The first one is "dax
semantics", which has been resolved. The rest two are "RMAP for
fsdax" and "support dax reflink for filesystem", which I have been
working on.
<nod>
So, what I want to confirm is: does it means that we can remove the
"EXPERIMENTAL" tag when the rest two problem are solved?
Yes. I'd keep the experimental tag for a cycle or two to make sure that
nothing new pops up, but otherwise the two patchsets you've sent close
those two big remaining gaps. Thank you for working on this!
Or maybe there are other important problems need to be fixed before
removing it? If there are, could you please show me that?
That remains to be seen through QA/validation, but I think that's it.
Granted, I still have to read through the two patchsets...
I've been meaning to circle back here as well.
My immediate concern is the issue Jason recently highlighted [1] with
respect to invalidating all dax mappings when / if the device is
ripped out from underneath the fs. I don't think that will collide
with Ruan's implementation, but it does need new communication from
driver to fs about removal events.
[1]: http://lore.kernel.org/r/CAPcyv4i+PZhYZiePf2PaH0dT5jDfkmkDX-3usQy1fAhf6LPyfw@xxxxxxxxxxxxxx
I'm not sure why there is a race condition between unbinding operation
and accessing mmaped file on filesystem dax yet.
May be silly question, but could you tell me why the "unbinding"
operation of the namespace which is mounted by filesystem dax must be
allowed?
If "unbinding" is rejected when the filesystem is mounted with dax
enabled, what is inconvenience?
I can imagine if a device like usb memory stick is removed surprisingly,
kernel/filesystem need to reject writeback at the time, and discard page
cache. Then, I can understand that unbinding operation is essential for
such case.
But I don't know why PMEM device/namespace allows unbinding operation
like surprising removal event.
Thanks,
--
Yasunori Goto
