From owner-freebsd-current@freebsd.org Mon Jun 5 18:17:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44A24AFE990 for ; Mon, 5 Jun 2017 18:17:15 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C510C64EB4 for ; Mon, 5 Jun 2017 18:17:14 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id n195so82597534wmg.1 for ; Mon, 05 Jun 2017 11:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=T4wpSQ0OD3EGGhTstZ025ZIC7p3/UXC4OiQ/uh27MUg=; b=ny+fk3UdQOWiIqozBdQPIcMJV4Vzwt6t83xZpMpGKWb/ZwKxzq7ectGL+EV3XS99CG 3vKK31+pr7P3pqN6osSFgq5/3xsP09JsffQbQ1U8To+DaCmjU8xdFmvYQTbMmPOjPfCm zYfSUy91ja/wKsbQXOIeDZH2I4/Esgg42a8WTiRETSyhCQJKkiwTfTUK/YGF+Yrr4gNm stwMaB9nPxCw5FQZd0nAtpHMpAMiTO5HO1Ct4HjMm4jfU3IG2dnCUoD9VO+6CvZ0uJk3 mX+rD5NK4lemWDHRbvIPExZqwZcT+WEdybUnbu28C/3kRSoMEDNSk4+4MJ48bWz7L6zf Hx+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=T4wpSQ0OD3EGGhTstZ025ZIC7p3/UXC4OiQ/uh27MUg=; b=IV/mhYOdcsOXEP1sti41JL+KHwm1clMe4XDV4rBshD7hUEYcLvEqVmX7JKpxCNFAew PqUYo7NJz9oRhaL1wtQWuAiWaQSEEq2yg2iceLT2LDcKXkL3/oAsnuYICVF0Oy8oGt3v kDVNDZOAFl3amhrGt896lKPudHyRfG4VmleQaP/A3rpNnwD++7wtfcu9yqWm4zCScjwy e6I+mqfB98lueW1TQq90A+SEgk2NU2RkbOU4Ldl1+N4u2kprCfS/U7JEZxUt6wHreFHM ns2ZqJ2Ps9jOhJ+S12/cDYmbPQ+NWzfDvfHxp4HY7WetbJxRo4tzv1H1EylWe4MHh20k iHpA== X-Gm-Message-State: AODbwcBseMQubZSJwhwROQFSdxK1gSqOZa4jxAfZdsaSAcxpiFp7HmMO bykt7+4lEOE3W8KS X-Received: by 10.28.20.14 with SMTP id 14mr9169441wmu.52.1496686632733; Mon, 05 Jun 2017 11:17:12 -0700 (PDT) Received: from brick (cpc92310-cmbg19-2-0-cust934.5-4.cable.virginm.net. [82.9.227.167]) by smtp.gmail.com with ESMTPSA id a127sm2365262wme.28.2017.06.05.11.17.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 11:17:11 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 5 Jun 2017 18:49:30 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Hans Petter Selasky Cc: Tomoaki AOKI , freebsd-current@freebsd.org Subject: Re: Time to increase MAXPHYS? Message-ID: <20170605174930.GA6259@brick> Mail-Followup-To: Hans Petter Selasky , Tomoaki AOKI , freebsd-current@freebsd.org References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> <20170604163948.eb5f74ce2a233b8f204ba671@dec.sakura.ne.jp> <15e42fd1-055d-28f6-5e24-1448e16954a9@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15e42fd1-055d-28f6-5e24-1448e16954a9@selasky.org> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 18:17:15 -0000 On 0604T0952, Hans Petter Selasky wrote: > On 06/04/17 09:39, Tomoaki AOKI wrote: > > Hi > > > > One possibility would be to make it MD build-time OTIONS, > > defaulting 1M on regular systems and 128k on smaller systems. > > > > Of course I guess making it a tunable (or sysctl) would be best, > > though. > > > > Hi, > > A tunable sysctl would be fine, but beware that commonly used firmware > out there produced in the millions might hang in a non-recoverable way > if you exceed their "internal limits". Conditionally lowering this > definition is fine, but increasing it needs to be carefully verified. > > For example many USB devices are only tested with OS'es like Windows and > MacOS and if these have any kind of limitation on the SCSI transfer > sizes, it is very likely many devices out there do not support any > larger transfer sizes either. FWIW, when testing cfiscsi(4) with Windows and OSX I've noticed that both issue 1MB requests. I wouldn't be surprised if they avoided doing that for older devices, depending on eg the SCSI version reported by device.