[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <yq1sk8rmqyl.fsf@sermon.lab.mkp.net>
Date: Tue, 23 Feb 2010 19:12:50 -0500
From: "Martin K. Petersen" <martin.petersen@...cle.com>
To: Mike Snitzer <snitzer@...hat.com>
Cc: "Martin K. Petersen" <martin.petersen@...cle.com>,
Christoph Hellwig <hch@...radead.org>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] block: warn if blk_stack_limits() undermines atomicity
>>>>> "Mike" == Mike Snitzer <snitzer@...hat.com> writes:
>> Not really. It'll be issued as one I/O with a smaller LBA count but
>> an identical data payload.
Mike> Can you expand on that a bit? How does a smaller LBA count relate
Mike> to this? On a 512b device the 4K data payload would touch more
Mike> LBAs.
Sorry, I had my head stuck in the 4KB case. More blocks. My point
being that regardless of the logical block size we'll be issuing a
single command. The only difference between the two cases is the LBA
count. I.e. the protocol encoding of how much data to transfer.
Mike> In any case, a 4K write to a 512b device is not atomic.
Mike> If you think what I've raised here is overblown then I'd like to
Mike> understand why in more detail.
I'm just playing devil's advocate here. We have no guarantees that a
512-byte write to a 512-byte device is atomic either. None. We've been
trying very hard to get any guarantees out of storage vendors for years
without any luck. I know that a lot of our stuff operate on the
assumption that sector writes are atomic. But in a lot of cases they
are not.
Mike> Otherwise all you have is a largely generic warning (as
Mike> blk_stack_limits knows nothing about which devices the provided
Mike> limits belong to).
Yeah, I had a patch at some point that distinguished between the various
error conditions instead of returning -1. I'll see if I can dig that
up...
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists