[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <x49k2nk0yvz.fsf@segfault.boston.devel.redhat.com>
Date: Fri, 08 Jan 2016 12:22:40 -0500
From: Jeff Moyer <jmoyer@...hat.com>
To: Dave Chinner <david@...morbit.com>
Cc: "Elliott\, Robert \(Persistent Memory\)" <elliott@....com>,
Ted Tso <tytso@....edu>,
"linux-nvdimm\@lists.01.org" <linux-nvdimm@...1.01.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
"xfs\@oss.sgi.com" <xfs@....sgi.com>,
"adilger.kernel\@dilger.ca" <adilger.kernel@...ger.ca>,
Cholerae Hu <choleraehyq@...il.com>,
"linux-ext4\@vger.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: A blocksize problem about dax and ext4
Dave Chinner <david@...morbit.com> writes:
>> 1. ext4 fails to mount the filesystem, while xfs just disables DAX.
>> It seems like they should they be the same.
I agree, it would be nice if they were the same.
> I don't really care what is done to ext4 here, but I'm not changing
> XFS behaviour. I'm expecting mixed dax/non-dax fileystems to be a
> thing, with DAX turned on by an inode flag on disk. Indeed, I see
> the mount option going away permanently for XFS, and DAX being
> controlled completely from on-disk flags. E.g. ext4 encrypted files
> need to turn off DAX, while clear text files can be accessed using
> DAX. This should happen completely transparently to the user....
The one thing we definitely need is a common way for an application to
open a file in dax mode. So, whatever ends up being the interface for
xfs in the future sure as heck better work for ext4.
I'm also not super keen on just getting rid of the dax mount option. I
understand why you'd want to do that, but I think it should stay, with
documentation on when you simply won't get dax mappings.
Please think about the poor programmers and system administrators that
have to use these interfaces.
Thanks,
Jeff
Powered by blists - more mailing lists