On Mon, Sep 04, 2017 at 05:44:53PM +0200, Christoph Hellwig wrote:
> > Does this test make sense when filesystem was mounted without dax
> > option? I saw these failures when testing on normal block device without
> > dax mount option.
>
> And thinking about it - why would we not allow setting the flag,
> especially given that right now it doesn't have a meaning either
> with or without DAX..
At least for the ext4 patches that have been crossing my screen, the
claim from the commit description is that with the dax mount option,
all files are treated as if the DAX flag. And the point of the DAX
flag is that if the file system is stored on DAX-capable hardware, and
you don't want DAX treatment for all files, that you would set the DAX
flag only for those files where having the file system actually using
the DAX codepaths would make sense --- as opposed to just using the
traditional block I/O paths against the /dev/pmem driver.
So I *think* the answer is that the tax makes sense when the file
system is mounted w/o the dax option, but we do need to check to see
whether the block device is DAX capable.
It also makes an interesting question how we should be testing DAX
capable file systems on /dev/pmem0. Right now I force the use of
/dev/pmem0 *and* use the DAX mount options so that all of the other
tests will cause file I/O to use the DAX path. But for the per-inode
DAX flag, we would want to mask out the DAX mount option so we can
test what happens when we toggle the DAX.
But I'm not a DAX expert, so I may have some of this wrong.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe fstests" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
