RE: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements

> From: linux-block-ow...@vger.kernel.org [mailto:linux-block- > ow...@vger.kernel.org] On Behalf Of Dexuan Cui > Sent: Friday, February 3, 2017 20:23 > To: Hannes Reinecke <h...@suse.com>; Bart Van Assche > <bart.vanass...@sandisk.com>; h...@suse.de; ax...@kernel.dk &

RE: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements

> From: Jens Axboe [mailto:ax...@kernel.dk] > Sent: Wednesday, February 8, 2017 00:09 > To: Dexuan Cui <de...@microsoft.com>; Bart Van Assche > <bart.vanass...@sandisk.com>; h...@suse.com; h...@suse.de > Cc: h...@lst.de; linux-ker...@vger.kernel.org; linux-block@vger.ke

RE: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements

> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Hannes Reinecke > Sent: Wednesday, February 1, 2017 00:15 > To: Bart Van Assche ; h...@suse.de; > ax...@kernel.dk > Cc: h...@lst.de; linux-ker...@vger.kernel.org;

RE: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

> From: h...@lst.de [mailto:h...@lst.de] > Sent: Thursday, February 9, 2017 02:03 > To: Jens Axboe <ax...@kernel.dk> > Cc: Dexuan Cui <de...@microsoft.com>; Bart Van Assche > <bart.vanass...@sandisk.com>; h...@suse.com; h...@suse.de; Martin K. > Petersen <m

RE: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

> From: h...@lst.de [mailto:h...@lst.de] > Sent: Tuesday, February 14, 2017 22:51 > To: Dexuan Cui <de...@microsoft.com> > Cc: h...@lst.de; Jens Axboe <ax...@kernel.dk>; Bart Van Assche > <bart.vanass...@sandisk.com>; h...@suse.com; h...@suse.de; Martin K. >

RE: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

> From: h...@lst.de [mailto:h...@lst.de] > Sent: Wednesday, February 15, 2017 00:35 > > I tested today's linux-next (next-20170214) + the 2 patches just now and > got > > a weird result: > > sometimes the VM stills hung with a new calltrace (BUG: spinlock bad > > magic) , but sometimes the VM did

RE: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

> From: h...@lst.de [mailto:h...@lst.de] > > Hi Dexuan, > > can you try the hack below for now? I disable the TUR call from > sd_check_events, which I think your VM is hanging on. The checks > it does on the sense data look a bit fishy, but so far I've not > identified a possible root cause. >

RE: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

> From: h...@lst.de [mailto:h...@lst.de] > Sent: Tuesday, February 14, 2017 22:29 > To: Dexuan Cui <de...@microsoft.com> > Subject: Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock > when scheduling workqueue elements") > > Ok, thanks for

RE: [PATCH RFC] block: fix bio merge checks when virt_boundary is set

> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Vitaly Kuznetsov > Sent: Wednesday, April 20, 2016 21:48 > To: Ming Lei > Cc: Keith Busch ; linux-block@vger.kernel.org; Linux > Kernel Mailing List

Big I/O requests are split into small ones due to unaligned ext4 partition boundary?

Hi, when I run "mkfs.ext4 /dev/sdc2" in a Linux virtual machine on Hyper-V, where a disk IOPS=500 limit is applied by me [0], the command takes much more time, if the ext4 partition boundary is not properly aligned: Example 1 [1]: it takes ~7 minutes with average wMB/s = 0.3 (slow) Example 2

RE: Big I/O requests are split into small ones due to unaligned ext4 partition boundary?

> From: Ming Lei [mailto:tom.leim...@gmail.com] > Sent: Thursday, December 15, 2016 20:43 > > On Thu, Dec 15, 2016 at 7:47 PM, Dexuan Cui <de...@microsoft.com> wrote: > > Hi, when I run "mkfs.ext4 /dev/sdc2" in a Linux virtual machine on Hyper-V, > > wher

RE: [Regression] fstrim hangs on Hyper-V: caused by "block: improve handling of the magic discard payload"

> From: Christoph Hellwig [mailto:h...@lst.de] > Sent: Friday, January 13, 2017 02:19 > To: Dexuan Cui <de...@microsoft.com> > Cc: linux-block@vger.kernel.org; KY Srinivasan <k...@microsoft.com>; Chris > Valean (Cloudbase Solutions SRL) <v-chv...@microsoft.com> &

RE: [Regression] fstrim hangs on Hyper-V: caused by "block: improve handling of the magic discard payload"

> From: Dexuan Cui > Sent: Friday, January 13, 2017 11:05 > To: 'Christoph Hellwig' <h...@lst.de> > Cc: linux-block@vger.kernel.org; KY Srinivasan <k...@microsoft.com>; Chris > Valean (Cloudbase Solutions SRL) <v-chv...@microsoft.com> > Subject: RE: [Regress

[Regression] fstrim hangs on Hyper-V: caused by "block: improve handling of the magic discard payload"

Hi, Recently fstrim and mkfs always hang in Linux VM running on Hyper-V 2012 R2 or 2016. The VM uses the latest mainline kernel (v4.10-rc3). git-bisect shows the patch "block: improve handling of the magic discard payload (f9d03f96)" causes the issue. If I revert the patch, the issue will go

RE: [Regression] fstrim hangs on Hyper-V: caused by "block: improve handling of the magic discard payload"

> From: Christoph Hellwig [mailto:h...@lst.de] > Sent: Thursday, January 12, 2017 21:44 > To: Dexuan Cui <de...@microsoft.com> > Cc: Christoph Hellwig <h...@lst.de>; linux-block@vger.kernel.org; Jens Axboe > <ax...@fb.com>; Vitaly Kuznetsov <vkuzn...@redhat.c

RE: [PATCH] block: loose check on sg gap

> From: Dexuan Cui > Sent: Tuesday, December 20, 2016 11:41 > To: 'Jens Axboe' <ax...@fb.com>; Ming Lei <ming@canonical.com> > Cc: Linux Kernel Mailing List <linux-ker...@vger.kernel.org>; linux-block > <linux-block@vger.kernel.org>; Christoph Hellwig &

RE: [PATCH] block: loose check on sg gap

> From: Jens Axboe [mailto:ax...@fb.com] > Sent: Tuesday, December 20, 2016 10:31 > To: Ming Lei <ming@canonical.com> > Cc: Linux Kernel Mailing List <linux-ker...@vger.kernel.org>; linux-block > bl...@vger.kernel.org>; Christoph Hellwig <h...