Hi Zhang,
> ping.
>
> Anyone can help merge this patch? or any other solutions?
+ /* If the logical block size is different, forbid write same */
+ if (t->logical_block_size != b->logical_block_size &&
+ t->max_write_same_sectors != UINT_MAX)
+ t->max_write_s
ping.
Anyone can help merge this patch? or any other solutions?
On 2/14/2019 5:36 PM, zhangxiaoxu (A) wrote:
Any comments about the patch?
On 2/14/2019 10:31 AM, Martin K. Petersen wrote:
zhangxiaoxu,
Any progress about the problme?
Should we disable the write same when stack the different
Any comments about the patch?
On 2/14/2019 10:31 AM, Martin K. Petersen wrote:
zhangxiaoxu,
Any progress about the problme?
Should we disable the write same when stack the different LBA disks?
Yes, please.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listin
zhangxiaoxu,
> Any progress about the problme?
> Should we disable the write same when stack the different LBA disks?
Yes, please.
--
Martin K. Petersen Oracle Linux Engineering
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Any progress about the problme?
Should we disable the write same when stack the different LBA disks?
On 2/2/2019 12:18 AM, Christoph Hellwig wrote:
On Fri, Feb 01, 2019 at 05:03:40PM +0100, Heinz Mauelshagen wrote:
On 2/1/19 3:09 PM, John Dorminy wrote:
I didn't know such a thing existed... do
On Fri, Feb 01, 2019 at 05:03:40PM +0100, Heinz Mauelshagen wrote:
> On 2/1/19 3:09 PM, John Dorminy wrote:
> > I didn't know such a thing existed... does it work on any block
> > device? Where do I read more about this?
>
>
> Use sg_write_same(8) from package sg3_utils.
>
> For instance 'sg_wri
On 2/1/19 3:09 PM, John Dorminy wrote:
I didn't know such a thing existed... does it work on any block
device? Where do I read more about this?
Use sg_write_same(8) from package sg3_utils.
For instance 'sg_write_same --in=foobarfile --lba=0 --num=2
--xferlen=512 /dev/sdwhatever'
will r
I didn't know such a thing existed... does it work on any block
device? Where do I read more about this?
On Fri, Feb 1, 2019 at 2:35 AM Christoph Hellwig wrote:
>
> On Thu, Jan 31, 2019 at 02:41:52PM -0500, John Dorminy wrote:
> > > On Wed, Jan 30, 2019 at 09:08:50AM -0500, John Dorminy wrote:
>
On Thu, Jan 31, 2019 at 02:41:52PM -0500, John Dorminy wrote:
> > On Wed, Jan 30, 2019 at 09:08:50AM -0500, John Dorminy wrote:
> > > (I use WRITE_SAME to fill devices with a particular pattern in order
> > > to catch failures to initialize disk structures appropriately,
> > > personally, but it's
On Thu, Jan 31, 2019 at 5:39 AM Christoph Hellwig wrote:
>
> On Wed, Jan 30, 2019 at 09:08:50AM -0500, John Dorminy wrote:
> > (I use WRITE_SAME to fill devices with a particular pattern in order
> > to catch failures to initialize disk structures appropriately,
> > personally, but it's just for c
On Wed, Jan 30, 2019 at 09:08:50AM -0500, John Dorminy wrote:
> (I use WRITE_SAME to fill devices with a particular pattern in order
> to catch failures to initialize disk structures appropriately,
> personally, but it's just for convenience/speed.)
How do you use it? We don't have a user interfa
On 1/30/2019 10:08 PM, John Dorminy wrote:
Alternately, could possibly WRITE_SAME bios be accepted with the
minimum sector size of the stack rather than the max, e.g. 512 in this
example rather than 4k? They'd need to have a granularity of the
larger sector size, though, presumabily necessitati
John,
>> So disallowing WRITE SAME unless all component devices have the same LBS
>> is the correct fix.
>
> Alternately, could possibly WRITE_SAME bios be accepted with the
> minimum sector size of the stack rather than the max, e.g. 512 in this
> example rather than 4k? They'd need to have a g
On Mon, Jan 28, 2019 at 11:54 PM Martin K. Petersen
wrote:
> We rounded up LBS when we created the DM device. And therefore the
> bv_len coming down is 4K. But one of the component devices has a LBS of
> 512 and fails this check.
>
> At first glance one could argue we should just nuke the BUG_ON s
On 1/29/2019 4:52 PM, Christoph Hellwig wrote:
On Mon, Jan 28, 2019 at 11:54:08PM -0500, Martin K. Petersen wrote:
That said, now that we have REQ_OP_WRITE_ZEROES (where the LBS is
irrelevant due to the payload being the ZERO_PAGE), it may be worthwhile
to remove REQ_OP_WRITE_SAME. I think dr
On Mon, Jan 28, 2019 at 11:54:08PM -0500, Martin K. Petersen wrote:
> That said, now that we have REQ_OP_WRITE_ZEROES (where the LBS is
> irrelevant due to the payload being the ZERO_PAGE), it may be worthwhile
> to remove REQ_OP_WRITE_SAME. I think drbd is the only user relying on a
> non-zero pay
Mike,
>> In the first place, if it's an LVM-only issue, we should fix it only
>> for device-mapper devices. If this is the right way to fix it,
>> possibly the way to do that would be to change DM calls to
>> blk_queue_max_write_same_sectors() to only set the max sectors to
>> more than 0 if and
On Sat, Jan 26 2019 at 6:17am -0500,
John Dorminy wrote:
> Hi. I have read a bit of DM code and spent an hour reviewing this... I
> didn't get to the point of knowing what the right fix for the problem
> is, and I may have a wrong understanding, but I have two thoughts
> about the patch:
>
> I
18 matches
Mail list logo
