From owner-freebsd-current@freebsd.org Sun Apr 10 15:15:57 2016 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 7BB78B0B3A5 for ; Sun, 10 Apr 2016 15:15:57 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 1872513B3 for ; Sun, 10 Apr 2016 15:15:56 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x234.google.com with SMTP id l6so116309572wml.1 for ; Sun, 10 Apr 2016 08:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=M8ULAvuZ+UsQ8kTpKsydtXptMLOq4OYFk1g1+zojJ94=; b=UJcCEo2BXgv2jr4Qr09kSGvKDV3fklKZ7faZ7DhZgQA4AM1OD8HT7INdnDStXJrZCR Ylk0W6nzVxi/SQn9bdwBabr40jAO+8VMqn1Pd0M682i2ZbJ6xxeNjjlI2PxzqCje+Tra G122jOp8qNbRJi5WUef4NzrYG57eXDyDpHlAgQ0OOE7I/m5vFsFgdzTg9mlETFSKy8f7 df3BRE8NWb47KO16DHXXLeUWt2yLbfa3LuBtQvRG6Z4G8QMlll2GogNEfLAuXnBtO9fx s7cdqb1uqNohxLMwUbh6isO9EgSCQHiMJ54jQkhZYBqxYb7Dc8vsDPXRsm7ISsxFockI Iq6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=M8ULAvuZ+UsQ8kTpKsydtXptMLOq4OYFk1g1+zojJ94=; b=EqeHWkazHsBM79MVgt74OqBlkmraoAAklQdArhGPOlaLJkv/p7QrR4ztMxPoc5DYU8 NBkt8TpXOErt2k1eXyqv4jmJaINMMrRrdP7ac1PsWiZ2wVUpdoiYLhzMbul0Au7EUgoq qvJ1t1ol3phdnQbGO5sE4TGkR9zWLvHSkDeesv4WgNxvtMf60HMp/RsXZdbVgz/GHye1 tdAVAsIYYoe+a+8YymdiQaTrdd1XAOYhInfdecb/ST7NEuaqtaY+FOoGgpN7o2QopKQE wG8oJgvFWS6c5fNXqYIipSNqSNW4N8mhvdz0YBWeMjXfvPK3ua7tw7boS4uCT+rdCAIz kf9g== X-Gm-Message-State: AD7BkJK3yiXmtwoyacb1hqhffLHAG8atBs/d36UWho6F8l80C+d3ElTLlLIclGnWmhK5bWiG X-Received: by 10.194.133.161 with SMTP id pd1mr21569831wjb.66.1460301354930; Sun, 10 Apr 2016 08:15:54 -0700 (PDT) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id jk1sm23241813wjb.27.2016.04.10.08.15.53 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Apr 2016 08:15:53 -0700 (PDT) Subject: Re: Question about cam 4K quirks To: freebsd-current@freebsd.org References: <20160410155621.82b751fa79f94ab2472264d7@dec.sakura.ne.jp> <20160410233510.2dd3c73b88f04aaf4b1b0ce6@dec.sakura.ne.jp> From: Steven Hartland Message-ID: <570A6E2C.2090601@multiplay.co.uk> Date: Sun, 10 Apr 2016 16:15:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160410233510.2dd3c73b88f04aaf4b1b0ce6@dec.sakura.ne.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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: Sun, 10 Apr 2016 15:15:57 -0000 On 10/04/2016 15:35, Tomoaki AOKI wrote: > On Sun, 10 Apr 2016 06:59:04 -0600 > Alan Somers wrote: > >> On Sun, Apr 10, 2016 at 12:56 AM, Tomoaki AOKI >> wrote: >> >>> Hi. Maybe freebsd-hardware list would be the right place, but it's not >>> so active. :-( >>> >>> Is 4K quirks needed for every HDDs/SSDs having physical sector size >>> 4096? >>> >>> If so, I would be able to provide patch for Crucial M550 and MX200. >>> (Possibly covers other models [BX200 etc.] by abstraction.) >>> >>> M550(1TB): device model Crucial CT1024M550SSD1 >>> firmware revision MU01 >>> MX200(1TB): device model Crucial CT1024MX200SSD1 >>> firmware revision MU03 >>> -> Abstracted with "Crucial CT*SSD*" or "Crucial CT*", as the part >>> "1024" should vary with its capacity and can be 3 to 4 digits >>> for now. I tried the former and confirmed "quirks=0x1<4K>" >>> appears, which doesn't appear without adding the entry. >>> >>> >>> If not, is it sufficient if `camcontrol identify ` states >>> "physical 4096" on "sector size" line for everything in kernel and >>> related components (i.e., zfs-related ones)? >>> >>> >>> Regards. >> >> You only need quirk entries if the device fails to identify its physical >> size correctly. If "camcontrol identify" states "physical 4096", then >> you're probably ok, but it's not the best place to ask. "camcontrol >> identify" asks the device directly, whereas "diskinfo -v" asks the kernel. >> If "diskinfo -v" says "4096 stripesize" then you're definitely ok. >> >> -Alan > Thanks for clarification. > > Tried "diskinfo -v" as you noted (of course running the kernel without > adding quirks entry) and confirmed it saying "4096 # stripesize". > So it's already OK with current ata_da.c and scsi_da.c (no quirks is > needed). > > OTOH, trying with Samsung 850 evo (the last one I have for now, > having quirks entry in current source), "diskinfo -v" says "4096 > # stripesize" while "camcontrol identify" says "physical 512". > This should be why quirks entries are needed (and implemented) for it. Correct, manufactures took the cop out route and return 512 for both logical and physical sizes to avoid issues with bad OS support. SSD's a particularly lazy in this regard. > I think stripesize should be primarily for RAID configuration, but > after 4k physical sectored drives (so called AFT drives) appears, > applied to even for single drive configuration, too. Right? stripesize simply gives a hit as to performance when accessing the device. > If so, as writing blocks smaller than stripesize (except for the last > block of a file) is nonsense for RAID configuration, all write access > to HDDs/SSDs are constrained to use stripesize for minimum block size, > right? Nope, sectorsize constrains that. stripesize is only used as a way to help tune filesystem access patterns e.g. in ZFS it is used to help determine the ashift value which in turn determines the minimum allocatable block size. This helps optimise performance while sacrificing storage space i.e. causing wastage. Regards Steve