lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 11 Mar 2020 20:00:09 -0700 (PDT) From: "Darrick J. Wong" <darrick.wong@...cle.com> To: Dave Chinner <david@...morbit.com> Cc: Christoph Hellwig <hch@....de>, Ira Weiny <ira.weiny@...el.com>, linux-kernel@...r.kernel.org, Alexander Viro <viro@...iv.linux.org.uk>, Dan Williams <dan.j.williams@...el.com>, "Theodore Y. Ts'o" <tytso@....edu>, Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org, akpm@...ux-foundation.org, torvalds@...ux-foundation.org Subject: Re: [PATCH V5 00/12] Enable per-file/per-directory DAX operations V5 On Thu, Mar 12, 2020 at 11:49:32AM +1100, Dave Chinner wrote: > On Wed, Mar 11, 2020 at 07:44:12AM +0100, Christoph Hellwig wrote: > > On Wed, Mar 11, 2020 at 05:39:42PM +1100, Dave Chinner wrote: > > > IOWs, the dax_associate_page() related functionality probably needs > > > to be a filesystem callout - part of the aops vector, I think, so > > > that device dax can still use it. That way XFS can go it's own way, > > > while ext4 and device dax can continue to use the existing mechanism > > > mechanisn that is currently implemented.... > > > > s/XFS/XFS with rmap/, as most XFS file systems currently don't have > > that enabled we'll also need to keep the legacy path around. > > Sure, that's trivially easy to handle in the XFS code once the > callouts are in place. > > But, quite frankly, we can enforce rmap to be enabled > enabled because nobody is using a reflink enabled FS w/ DAX right > now. Everyone will have to mkfs their filesystems anyway to enable > reflink+dax, so we simply don't allow reflink+dax to be enabled > unless rmap is also enabled. Simple, easy, trivial. Heh, this reminds me that I need to get that rmap performance analysis report out to the list... it does have a fairly substantial performance impact (in its current not-terribly-optimized state) but otoh enables self-repair. --D > Cheers, > > Dave. > -- > Dave Chinner > david@...morbit.com
Powered by blists - more mailing lists