Re: [dm-devel] [PATCH] dm snapshot: add optional discard support features

Hi Mike, A question inline. On 7/3/19 7:25 PM, Mike Snitzer wrote: > Add 2 _optional_ features to the snapshot target: > > discard_zeroes_cow - a discard issued to the snapshot device that maps > to entire chunks to will zero the corresponding exception(s) in the > snapshot's exception store. >

[PATCH v15 7/7] xfs: disable map_sync for async flush

Dont support 'MAP_SYNC' with non-DAX files and DAX files with asynchronous dax_device. Virtio pmem provides asynchronous host page cache flush mechanism. We don't support 'MAP_SYNC' with virtio pmem and xfs. Signed-off-by: Pankaj Gupta Reviewed-by: Darrick J. Wong --- fs/xfs/xfs_file.c | 9

[PATCH v15 6/7] ext4: disable map_sync for async flush

Dont support 'MAP_SYNC' with non-DAX files and DAX files with asynchronous dax_device. Virtio pmem provides asynchronous host page cache flush mechanism. We don't support 'MAP_SYNC' with virtio pmem and ext4. Signed-off-by: Pankaj Gupta Reviewed-by: Jan Kara --- fs/ext4/file.c | 10 ++

[PATCH v15 5/7] dax: check synchronous mapping is supported

This patch introduces 'daxdev_mapping_supported' helper which checks if 'MAP_SYNC' is supported with filesystem mapping. It also checks if corresponding dax_device is synchronous. Virtio pmem device is asynchronous and does not not support VM_SYNC. Suggested-by: Jan Kara Signed-off-by: Pankaj

[PATCH v15 4/7] dm: enable synchronous dax

This patch sets dax device 'DAXDEV_SYNC' flag if all the target devices of device mapper support synchrononous DAX. If device mapper consists of both synchronous and asynchronous dax devices, we don't set 'DAXDEV_SYNC' flag. 'dm_table_supports_dax' is refactored to pass 'iterate_devices_fn' as

[PATCH v15 3/7] libnvdimm: add dax_dev sync flag

This patch adds 'DAXDEV_SYNC' flag which is set for nd_region doing synchronous flush. This later is used to disable MAP_SYNC functionality for ext4 & xfs filesystem for devices don't support synchronous flush. Signed-off-by: Pankaj Gupta --- drivers/dax/bus.c| 2 +-

[PATCH v15 2/7] virtio-pmem: Add virtio pmem driver

This patch adds virtio-pmem driver for KVM guest. Guest reads the persistent memory range information from Qemu over VIRTIO and registers it on nvdimm_bus. It also creates a nd_region object with the persistent memory range information so that existing 'nvdimm/pmem' driver can reserve this into

[PATCH v15 1/7] libnvdimm: nd_region flush callback support

This patch adds functionality to perform flush from guest to host over VIRTIO. We are registering a callback based on 'nd_region' type. virtio_pmem driver requires this special flush function. For rest of the region types we are registering existing flush function. Report error returned by host

Re: [PATCH 3/3] dm-crypt: Implement eboiv - encrypted byte-offset initialization vector.

On Fri, Jul 05, 2019 at 08:32:03AM +0200, Ard Biesheuvel wrote: > > > AFAICS this is using the same key as the actual data. So why > > don't you combine it with the actual data when encrypting/decrypting? > > > > That is, add a block at the front of the actual data containing > > the

Re: [PATCH v8 0/7] crypto: switch to crypto API for ESSIV generation

On Thu, 4 Jul 2019 at 20:30, Ard Biesheuvel wrote: > > This series creates an ESSIV template that produces a skcipher or AEAD > transform based on a tuple of the form ',,' > (or ',,' for the AEAD case). It exposes the > encapsulated sync or async skcipher/aead by passing through all operations, >

Re: [PATCH 3/3] dm-crypt: Implement eboiv - encrypted byte-offset initialization vector.

On Fri, 5 Jul 2019 at 05:08, Herbert Xu wrote: > > On Thu, Jul 04, 2019 at 08:11:46PM +0200, Ard Biesheuvel wrote: > > > > To be clear, making the cipher API internal only is something that I > > am proposing but hasn't been widely discussed yet. So if you make a > > good argument why it is a