diff for duplicates of <1466014718999.6976@vmware.com> diff --git a/a/1.txt b/N1/1.txt index 7191455..ffb4597 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,49 +1,35 @@ -It is possibly some race. We saw a WRITE SAME related issue in past for whi= -ch Petr sent out a patch but looks like the patch didn't make it. :(=0A= -=0A= -https://groups.google.com/forum/#!topic/linux.kernel/1WGDSlyY0y0=0A= -=0A= -Thanks!=0A= -Arvind=0A= -________________________________________=0A= -From: Sitsofe Wheeler <sitsofe@gmail.com>=0A= -Sent: Tuesday, May 31, 2016 10:04 PM=0A= -To: Tom Yan=0A= -Cc: Darrick J. Wong; Shaohua Li; Jens Axboe; Arvind Kumar; VMware PV-Driver= -s; linux-raid@vger.kernel.org; linux-scsi@vger.kernel.org; linux-block@vger= -.kernel.org; linux-kernel@vger.kernel.org=0A= -Subject: Re: BLKZEROOUT not zeroing md dev on VMDK=0A= -=0A= -On 27 May 2016 at 10:30, Tom Yan <tom.ty89@gmail.com> wrote:=0A= -> There seems to be some sort of race condition between=0A= -> blkdev_issue_zeroout() and the scsi disk driver (disabling write same=0A= -> after an illegal request). On my UAS drive, sometimes `blkdiscard -z=0A= -> /dev/sdX` will return right away, even though if I then check=0A= -> `write_same_max_bytes` it has turned 0. Sometimes it will just write=0A= -> zero with SCSI WRITE even if `write_same_max_bytes` is 33553920 before=0A= -> I issue `blkdiscard -z` (`write_same_max_bytes` also turned 0, as=0A= -> expected).=0A= ->=0A= -> Not sure if it is directly related to the case here though.=0A= -=0A= -I'm not aware of hitting that particular problem myself directly on=0A= -the underlying "SCSI" device but the patch on=0A= -https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__patchwork.kernel.org= -_patch_9137311_&d=3DCwIBaQ&c=3DSqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&= -r=3DbUMaNc7nC9xbXtaMJrOvIIPNpPH0chY2kdRsskQn6GY&m=3Drx_5ntfhkt2GOpfjpiQjoCb= -5n4gCY7jKznXO0gKYcVI&s=3DW1F45VBu8NDxu2ImcbKM5b3d6UnUCLGgH8xEM9e6JQk&e=3D = -should be able to resolve=0A= -that issue. Could you test it and follow up on=0A= -https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__permalink.gmane.org_g= -mane.linux.kernel_2229377&d=3DCwIBaQ&c=3DSqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihV= -MNtXt-uEs&r=3DbUMaNc7nC9xbXtaMJrOvIIPNpPH0chY2kdRsskQn6GY&m=3Drx_5ntfhkt2GO= -pfjpiQjoCb5n4gCY7jKznXO0gKYcVI&s=3D9ekqmTk18vzcwcY0SSMF8AZnJ_lWezFIM8tDvQqe= -DHI&e=3D ? I'm hoping=0A= -more testing reports will lead to the patch being reviewed and=0A= -accepted sooner rather than later as it's currently stalled...=0A= -=0A= ---=0A= -Sitsofe | https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__sucs.org_-7= -Esits_&d=3DCwIBaQ&c=3DSqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=3DbUMaN= -c7nC9xbXtaMJrOvIIPNpPH0chY2kdRsskQn6GY&m=3Drx_5ntfhkt2GOpfjpiQjoCb5n4gCY7jK= -znXO0gKYcVI&s=3DarwniVbdl5KJZfyreWLhq-WUlgvKAf_eW1i6D2GbFGQ&e=3D=0A= +It is possibly some race. We saw a WRITE SAME related issue in past for which Petr sent out a patch but looks like the patch didn't make it. :( + +https://groups.google.com/forum/#!topic/linux.kernel/1WGDSlyY0y0 + +Thanks! +Arvind +________________________________________ +From: Sitsofe Wheeler <sitsofe@gmail.com> +Sent: Tuesday, May 31, 2016 10:04 PM +To: Tom Yan +Cc: Darrick J. Wong; Shaohua Li; Jens Axboe; Arvind Kumar; VMware PV-Drivers; linux-raid@vger.kernel.org; linux-scsi@vger.kernel.org; linux-block@vger.kernel.org; linux-kernel@vger.kernel.org +Subject: Re: BLKZEROOUT not zeroing md dev on VMDK + +On 27 May 2016 at 10:30, Tom Yan <tom.ty89@gmail.com> wrote: +> There seems to be some sort of race condition between +> blkdev_issue_zeroout() and the scsi disk driver (disabling write same +> after an illegal request). On my UAS drive, sometimes `blkdiscard -z +> /dev/sdX` will return right away, even though if I then check +> `write_same_max_bytes` it has turned 0. Sometimes it will just write +> zero with SCSI WRITE even if `write_same_max_bytes` is 33553920 before +> I issue `blkdiscard -z` (`write_same_max_bytes` also turned 0, as +> expected). +> +> Not sure if it is directly related to the case here though. + +I'm not aware of hitting that particular problem myself directly on +the underlying "SCSI" device but the patch on +https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_9137311_&d=CwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=bUMaNc7nC9xbXtaMJrOvIIPNpPH0chY2kdRsskQn6GY&m=rx_5ntfhkt2GOpfjpiQjoCb5n4gCY7jKznXO0gKYcVI&s=W1F45VBu8NDxu2ImcbKM5b3d6UnUCLGgH8xEM9e6JQk&e= should be able to resolve +that issue. Could you test it and follow up on +https://urldefense.proofpoint.com/v2/url?u=http-3A__permalink.gmane.org_gmane.linux.kernel_2229377&d=CwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=bUMaNc7nC9xbXtaMJrOvIIPNpPH0chY2kdRsskQn6GY&m=rx_5ntfhkt2GOpfjpiQjoCb5n4gCY7jKznXO0gKYcVI&s=9ekqmTk18vzcwcY0SSMF8AZnJ_lWezFIM8tDvQqeDHI&e= ? I'm hoping +more testing reports will lead to the patch being reviewed and +accepted sooner rather than later as it's currently stalled... + +-- +Sitsofe | https://urldefense.proofpoint.com/v2/url?u=http-3A__sucs.org_-7Esits_&d=CwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=bUMaNc7nC9xbXtaMJrOvIIPNpPH0chY2kdRsskQn6GY&m=rx_5ntfhkt2GOpfjpiQjoCb5n4gCY7jKznXO0gKYcVI&s=arwniVbdl5KJZfyreWLhq-WUlgvKAf_eW1i6D2GbFGQ&e= diff --git a/a/content_digest b/N1/content_digest index 2024b0f..7a8f339 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -19,54 +19,40 @@ " Petr Vandrovec <petr@vmware.com>\0" "\00:1\0" "b\0" - "It is possibly some race. We saw a WRITE SAME related issue in past for whi=\n" - "ch Petr sent out a patch but looks like the patch didn't make it. :(=0A=\n" - "=0A=\n" - "https://groups.google.com/forum/#!topic/linux.kernel/1WGDSlyY0y0=0A=\n" - "=0A=\n" - "Thanks!=0A=\n" - "Arvind=0A=\n" - "________________________________________=0A=\n" - "From: Sitsofe Wheeler <sitsofe@gmail.com>=0A=\n" - "Sent: Tuesday, May 31, 2016 10:04 PM=0A=\n" - "To: Tom Yan=0A=\n" - "Cc: Darrick J. Wong; Shaohua Li; Jens Axboe; Arvind Kumar; VMware PV-Driver=\n" - "s; linux-raid@vger.kernel.org; linux-scsi@vger.kernel.org; linux-block@vger=\n" - ".kernel.org; linux-kernel@vger.kernel.org=0A=\n" - "Subject: Re: BLKZEROOUT not zeroing md dev on VMDK=0A=\n" - "=0A=\n" - "On 27 May 2016 at 10:30, Tom Yan <tom.ty89@gmail.com> wrote:=0A=\n" - "> There seems to be some sort of race condition between=0A=\n" - "> blkdev_issue_zeroout() and the scsi disk driver (disabling write same=0A=\n" - "> after an illegal request). On my UAS drive, sometimes `blkdiscard -z=0A=\n" - "> /dev/sdX` will return right away, even though if I then check=0A=\n" - "> `write_same_max_bytes` it has turned 0. Sometimes it will just write=0A=\n" - "> zero with SCSI WRITE even if `write_same_max_bytes` is 33553920 before=0A=\n" - "> I issue `blkdiscard -z` (`write_same_max_bytes` also turned 0, as=0A=\n" - "> expected).=0A=\n" - ">=0A=\n" - "> Not sure if it is directly related to the case here though.=0A=\n" - "=0A=\n" - "I'm not aware of hitting that particular problem myself directly on=0A=\n" - "the underlying \"SCSI\" device but the patch on=0A=\n" - "https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__patchwork.kernel.org=\n" - "_patch_9137311_&d=3DCwIBaQ&c=3DSqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&=\n" - "r=3DbUMaNc7nC9xbXtaMJrOvIIPNpPH0chY2kdRsskQn6GY&m=3Drx_5ntfhkt2GOpfjpiQjoCb=\n" - "5n4gCY7jKznXO0gKYcVI&s=3DW1F45VBu8NDxu2ImcbKM5b3d6UnUCLGgH8xEM9e6JQk&e=3D =\n" - "should be able to resolve=0A=\n" - "that issue. Could you test it and follow up on=0A=\n" - "https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__permalink.gmane.org_g=\n" - "mane.linux.kernel_2229377&d=3DCwIBaQ&c=3DSqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihV=\n" - "MNtXt-uEs&r=3DbUMaNc7nC9xbXtaMJrOvIIPNpPH0chY2kdRsskQn6GY&m=3Drx_5ntfhkt2GO=\n" - "pfjpiQjoCb5n4gCY7jKznXO0gKYcVI&s=3D9ekqmTk18vzcwcY0SSMF8AZnJ_lWezFIM8tDvQqe=\n" - "DHI&e=3D ? I'm hoping=0A=\n" - "more testing reports will lead to the patch being reviewed and=0A=\n" - "accepted sooner rather than later as it's currently stalled...=0A=\n" - "=0A=\n" - "--=0A=\n" - "Sitsofe | https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__sucs.org_-7=\n" - "Esits_&d=3DCwIBaQ&c=3DSqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=3DbUMaN=\n" - "c7nC9xbXtaMJrOvIIPNpPH0chY2kdRsskQn6GY&m=3Drx_5ntfhkt2GOpfjpiQjoCb5n4gCY7jK=\n" - znXO0gKYcVI&s=3DarwniVbdl5KJZfyreWLhq-WUlgvKAf_eW1i6D2GbFGQ&e=3D=0A= + "It is possibly some race. We saw a WRITE SAME related issue in past for which Petr sent out a patch but looks like the patch didn't make it. :(\n" + "\n" + "https://groups.google.com/forum/#!topic/linux.kernel/1WGDSlyY0y0\n" + "\n" + "Thanks!\n" + "Arvind\n" + "________________________________________\n" + "From: Sitsofe Wheeler <sitsofe@gmail.com>\n" + "Sent: Tuesday, May 31, 2016 10:04 PM\n" + "To: Tom Yan\n" + "Cc: Darrick J. Wong; Shaohua Li; Jens Axboe; Arvind Kumar; VMware PV-Drivers; linux-raid@vger.kernel.org; linux-scsi@vger.kernel.org; linux-block@vger.kernel.org; linux-kernel@vger.kernel.org\n" + "Subject: Re: BLKZEROOUT not zeroing md dev on VMDK\n" + "\n" + "On 27 May 2016 at 10:30, Tom Yan <tom.ty89@gmail.com> wrote:\n" + "> There seems to be some sort of race condition between\n" + "> blkdev_issue_zeroout() and the scsi disk driver (disabling write same\n" + "> after an illegal request). On my UAS drive, sometimes `blkdiscard -z\n" + "> /dev/sdX` will return right away, even though if I then check\n" + "> `write_same_max_bytes` it has turned 0. Sometimes it will just write\n" + "> zero with SCSI WRITE even if `write_same_max_bytes` is 33553920 before\n" + "> I issue `blkdiscard -z` (`write_same_max_bytes` also turned 0, as\n" + "> expected).\n" + ">\n" + "> Not sure if it is directly related to the case here though.\n" + "\n" + "I'm not aware of hitting that particular problem myself directly on\n" + "the underlying \"SCSI\" device but the patch on\n" + "https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_9137311_&d=CwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=bUMaNc7nC9xbXtaMJrOvIIPNpPH0chY2kdRsskQn6GY&m=rx_5ntfhkt2GOpfjpiQjoCb5n4gCY7jKznXO0gKYcVI&s=W1F45VBu8NDxu2ImcbKM5b3d6UnUCLGgH8xEM9e6JQk&e= should be able to resolve\n" + "that issue. Could you test it and follow up on\n" + "https://urldefense.proofpoint.com/v2/url?u=http-3A__permalink.gmane.org_gmane.linux.kernel_2229377&d=CwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=bUMaNc7nC9xbXtaMJrOvIIPNpPH0chY2kdRsskQn6GY&m=rx_5ntfhkt2GOpfjpiQjoCb5n4gCY7jKznXO0gKYcVI&s=9ekqmTk18vzcwcY0SSMF8AZnJ_lWezFIM8tDvQqeDHI&e= ? I'm hoping\n" + "more testing reports will lead to the patch being reviewed and\n" + "accepted sooner rather than later as it's currently stalled...\n" + "\n" + "--\n" + Sitsofe | https://urldefense.proofpoint.com/v2/url?u=http-3A__sucs.org_-7Esits_&d=CwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=bUMaNc7nC9xbXtaMJrOvIIPNpPH0chY2kdRsskQn6GY&m=rx_5ntfhkt2GOpfjpiQjoCb5n4gCY7jKznXO0gKYcVI&s=arwniVbdl5KJZfyreWLhq-WUlgvKAf_eW1i6D2GbFGQ&e= -0764c019e4b1eded64f845a669194157c515255974861c9c1d54e1213f5151ad +97ab299a5ede9327eff575662438fbb817572dbe1dbb90189375a7c65ccf2058
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.