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: Mon, 23 Oct 2017 13:34:09 -0400 From: Josef Bacik <josef@...icpanda.com> To: Ross Zwisler <ross.zwisler@...ux.intel.com> Cc: linux-kernel@...r.kernel.org, Josef Bacik <jbacik@...com>, Alasdair Kergon <agk@...hat.com>, Dan Williams <dan.j.williams@...el.com>, Dave Chinner <david@...morbit.com>, Jan Kara <jack@...e.cz>, Mike Snitzer <snitzer@...hat.com>, Shaohua Li <shli@...nel.org>, dm-devel@...hat.com, linux-nvdimm@...ts.01.org, linux-raid@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org, Christoph Hellwig <hch@...radead.org> Subject: Re: [PATCH 2/2] dm log writes: add support for DAX On Thu, Oct 19, 2017 at 11:24:04PM -0600, Ross Zwisler wrote: > Now that we have the ability log filesystem writes using a flat buffer, add > support for DAX. Unfortunately we can't easily track data that has been > written via mmap() now that the dax_flush() abstraction was removed by this > commit: > > commit c3ca015fab6d ("dax: remove the pmem_dax_ops->flush abstraction") > > Otherwise we could just treat each flush as a big write, and store the data > that is being synced to media. It may be worthwhile to add the dax_flush() > entry point back, just as a notifier so we can do this logging. > > The motivation for this support is the need for an xfstest that can test > the new MAP_SYNC DAX flag. By logging the filesystem activity with > dm-log-writes we can show that the MAP_SYNC page faults are writing out > their metadata as they happen, instead of requiring an explicit > msync/fsync. > > Signed-off-by: Ross Zwisler <ross.zwisler@...ux.intel.com> > --- Ok this is just my ignorance of how DAX works shining through, but do we need a new flag to indicate this is DAX data? You are logging it like it's just normal data going to a certain sector, is that good enough? If it is then hooray this looks fine to me, I'm just slightly confused. Thanks, Josef
Powered by blists - more mailing lists