From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756411AbbGTUob (ORCPT ); Mon, 20 Jul 2015 16:44:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52308 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754027AbbGTUo2 (ORCPT ); Mon, 20 Jul 2015 16:44:28 -0400 From: Jeff Moyer To: Jens Axboe Cc: Christoph Hellwig , linux-kernel@vger.kernel.org, dmilburn@redhat.com Subject: Re: [patch] Revert "block: remove artifical max_hw_sectors cap" References: <55AD5902.7020209@kernel.dk> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Date: Mon, 20 Jul 2015 16:44:26 -0400 In-Reply-To: <55AD5902.7020209@kernel.dk> (Jens Axboe's message of "Mon, 20 Jul 2015 14:24:34 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jens Axboe writes: > On 07/20/2015 01:17 PM, Jeff Moyer wrote: >> >> >> >> Hi, >> >> This reverts commit 34b48db66e08, which caused significant iozone >> performance regressions and uncovered a silent data corruption >> bug in at least one disk. >> >> For SAN storage, we've seen initial write and re-write performance drop >> 25-50% across all I/O sizes. On locally attached storage, we've seen >> regressions of 40% for all I/O types, but only for I/O sizes larger than >> 1MB. > > Do we have any understanding of where this regression is coming from? > Even just basic info like iostats from a run would be useful. I'll request this information and get back to you. Sorry, I should have done more digging first, but this seemed somewhat urgent to me. >> In addition to the performance issues, we've also seen data corruption >> on one disk/hba combination. See >> http://marc.info/?l=linux-ide&m=143680539400526&w=2 > > That's just sucky hardware... That said, it is indeed one of the > risks. We had basically the same transition from 255 as max sectors, > since we depended on ATA treating 0 == 256 sectors (as per spec). Sure, the hardware sucks. I still don't like foisting silent data corruption on users. Besides, given that this patch went in without any performance numbers attached, I'd say the risk/reward ratio right now is in favor of the revert. Cheers, Jeff