[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgOu9vgUfOSsjO3hHHxGDn4BKhitC_8XCfgmGKiiSm_ag@mail.gmail.com>
Date: Tue, 1 Dec 2020 12:04:56 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Eric Sandeen <sandeen@...hat.com>
Cc: Miklos Szeredi <mszeredi@...hat.com>,
Ira Weiny <ira.weiny@...el.com>,
David Howells <dhowells@...hat.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-man <linux-man@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
xfs <linux-xfs@...r.kernel.org>,
Ext4 Developers List <linux-ext4@...r.kernel.org>,
Xiaoli Feng <xifeng@...hat.com>
Subject: Re: [PATCH 2/2] statx: move STATX_ATTR_DAX attribute handling to filesystems
On Tue, Dec 1, 2020 at 8:59 AM Eric Sandeen <sandeen@...hat.com> wrote:
>
> It's a bit odd to set STATX_ATTR_DAX into the statx attributes in the VFS;
> while the VFS can detect the current DAX state, it is the filesystem which
> actually sets S_DAX on the inode, and the filesystem is the place that
> knows whether DAX is something that the "filesystem actually supports" [1]
> so that the statx attributes_mask can be properly set.
>
> So, move STATX_ATTR_DAX attribute setting to the individual dax-capable
> filesystems, and update the attributes_mask there as well.
I'm not really understanding the logic behind this.
The whole IS_DAX(inode) thing exists in various places outside the
low-level filesystem, why shouldn't stat() do this?
If IS_DAX() is incorrect, then we have much bigger problems than some
stat results. We have core functions like generic_file_read_iter() etc
all making actual behavioral judgements on IS_DAX().
And if IS_DAX() is correct, then why shouldn't this just be done in
generic code? Why move it to every individual filesystem?
Linus
Powered by blists - more mailing lists