On Mon, Dec 29, 2014 at 09:07:59PM +, KY Srinivasan wrote:
> Should I be resending these patches.
I don't need a resend, I need a review for the patches. Note that for
driver patches I'm also fine with a review from a co worker, as long as
it's a real review not just a rubber stamp.
Talking
On Wed, Jul 09, 2014 at 10:36:26PM +, KY Srinivasan wrote:
> Ok; I am concerned about older kernels that do not have no_write_same flag.
> I suppose I can work directly with these Distros and give them a choice:
> either implement
> the no_write_same flag or filter the command in our driver. I
On Wed, Jul 09, 2014 at 10:27:24PM +, James Bottomley wrote:
> If we fix it at source, why would there be any need to filter? That's
> the reason the no_write_same flag was introduced. If we can find and
> fix the bug, it can go back into the stable trees as a bug fix, hence
> nothing should
On Sun, Jul 13, 2014 at 08:58:34AM -0400, Martin K. Petersen wrote:
> > "KY" == KY Srinivasan writes:
>
> KY> Windows hosts do support UNMAP and set the field in the
> KY> EVPD. However, since the host advertises SPC-2 compliance, Linux
> KY> does not even query the VPD page.
>
> >> If we w
On Wed, Jul 16, 2014 at 11:44:18AM -0400, Martin K. Petersen wrote:
> There are lots of devices out there that support WRITE SAME(10) or (16)
> without the UNMAP bit. And there are devices that support WRITE SAME w/
> UNMAP functionality but not "regular" WRITE SAME.
Oh, we actually have devices t
On Wed, Jul 16, 2014 at 01:47:35PM -0400, Martin K. Petersen wrote:
> There were several SSDs that did not want to support wearing out flash
> by writing gobs of zeroes and only support the UNMAP case.
Given that SSDs usually aren't hard provisioned anyway that seems like
an odd decision. But SAS
On Wed, Jul 16, 2014 at 03:20:00PM -0400, Martin K. Petersen wrote:
> The block layer can only describe one contiguous block range in a
> request. My copy offload patches introduces the bi_special field that
> allows us to attach additional information to an I/O. I have
> experimented with doing th
On Fri, Jul 18, 2014 at 04:57:13PM +, James Bottomley wrote:
> Actually, no you didn't. The difference is in the derivation of the
> timeout. Christoph's patch is absolute in terms of SD_TIMEOUT; yours is
> relative to the queue timeout setting ... I thought there was a reason
> for preferrin
This is what I plan to put in after it passes basic testing:
---
>From bb617c9465b839d70ecbbc69002a20ccf5f935bd Mon Sep 17 00:00:00 2001
From: "K. Y. Srinivasan"
Date: Fri, 18 Jul 2014 19:12:58 +0200
Subject: sd: fix a bug in deriving the FLUSH_TIMEOUT from the basic I/O
timeout
Commit ID: 7e66
On Fri, Jul 18, 2014 at 10:12:38AM -0700, h...@infradead.org wrote:
> This is what I plan to put in after it passes basic testing:
And that one was on top of my previous version. One that applies
against core-for-3.17 below:
---
>From 8a79783e5f72ec034a724e16c1f46604bd97bf68 Mon Sep 17 00
On Thu, Jul 17, 2014 at 11:53:33PM +, KY Srinivasan wrote:
> I still see this problem. There was talk of fixing it elsewhere.
Well, what we have right not is entirely broken, given that the
block layer doesn't initialize ->timeout on TYPE_FS requeuests.
We either need to revert that initial c
On Fri, Jul 18, 2014 at 12:51:06AM +, Elliott, Robert (Server Storage)
wrote:
> SYNCHRONIZE CACHE (16) should be favored over SYNCHRONIZE
> CACHE (10) unless SYNCHRONIZE CACHE (10) is not supported.
I gues you mean (16) for the last occurance? What's the benefit of
using SYNCHRONIZE CACHE (
12 matches
Mail list logo
