Re: [dm-devel] [LSF/MM/BFP ATTEND] [LSF/MM/BFP TOPIC] Storage: Copy Offload

2020-02-20 Thread Knight, Frederick
tias Bjorling' ; 'Stephen Bates' ; rol...@purestorage.com; josh...@samsung.com; mpato...@redhat.com; h...@suse.de; 'Keith Busch' ; rwhee...@redhat.com; 'Christoph Hellwig' ; Knight, Frederick ; zach.br...@ni.com; josh...@samsung.com; jav...@javigon.com Subject: RE: [L

Re: [dm-devel] [LSF/MM/BFP ATTEND] [LSF/MM/BFP TOPIC] Storage: Copy Offload

2021-05-12 Thread Knight, Frederick
ax...@kernel.dk; msnit...@redhat.com; bvanass...@acm.org; martin.peter...@oracle.com; rol...@purestorage.com; mpato...@redhat.com; Hannes Reinecke ; kbu...@kernel.org; rwhee...@redhat.com; h...@lst.de; Knight, Frederick ; zach.br...@ni.com; osan...@fb.com Subject: [LSF/MM/BFP ATTEND] [LSF/MM/BFP TOPIC] S

Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at LSF/MM

2016-04-29 Thread Knight, Frederick
There are multiple possible situations being intermixed in this discussion. First, I assume you're talking only about random access devices (if you try transport level error recover on a sequential access device - tape or SMR disk - there are lots of additional complexities). Failures can occu