From owner-freebsd-current@freebsd.org Mon Apr 11 15:07:04 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 9886DB0B740 for ; Mon, 11 Apr 2016 15:07:04 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 31ECA1B23 for ; Mon, 11 Apr 2016 15:07:03 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x22f.google.com with SMTP id a140so16972940wma.0 for ; Mon, 11 Apr 2016 08:07:03 -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=lFbaPymx+bIHrh6ZY+UTmqdTKpkEFjH+LmEHfwa71pw=; b=aRmyd68vmp5sUoGc0O9OCnfsi4dTJgOAevbNcXLZ6R/O6Nc4AORdu69CVzs0k20X0P eIbdtctOJLfC1LIPLNZxRaBvAbdXJ2mB8Xi+yG3C2lCukH7Jvy0OpkkB074HmoXnfSw9 Ec+jW4wDpyaVsBhOGPE2IRAeilju6adRRss59lWFgliRQM/V6q7mvN7T/LXGzJEQxd+z zSD1EMWlst3HHaIe+DtF95P1hpEIutIToUMT/OtBGsqE3izT/EeyfCKvaeHNOu2uX6Ts gueHtz4nu1ZCP73qhuIf8B9QyyG3WJh5YlimU4zVWlhs6Db72Sf6l0r4ZwITorpjjeD7 z1WA== 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=lFbaPymx+bIHrh6ZY+UTmqdTKpkEFjH+LmEHfwa71pw=; b=dnNf7OLyx8vYIVjuh+5VE4UruWMvHL9iK5exqaAwVXiYSTe1gEtSrmh0VcUU0lukaC fJheJbGgeUXCuo/+pvrb7WhHcOGlVtYjpE1af62bW2DnFWlFfmhnzsjaY4XgaYwcN5MK BVxj0F9RVk16HpXd0K3MhP606grNnQrdfi10SCRLcDciO5XbnnCA0BOvfO8qxrngCIT9 tf2yNFNUuC7PFF5BR27XA1rzcDDN5WpEx49gN2I5wpwu9OgWD6XUhUGNbLUB343TJclH mGczM6jFTr5RDcrAuo9mIm/S3Zx8xwT2alemQExs8hv54A6xTIVgcui1d8Brg+1pDAfs l3RQ== X-Gm-Message-State: AD7BkJJVy6d4jfO4Jc7KVQz/D9Axb2mRiF1vuR27jJQ48tEb0IuDo4rmG0OC06r1YpBFOhx/ X-Received: by 10.194.135.6 with SMTP id po6mr22218610wjb.70.1460387221169; Mon, 11 Apr 2016 08:07:01 -0700 (PDT) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id j71sm17814849wmj.21.2016.04.11.08.06.59 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Apr 2016 08:06:59 -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> <570A6E2C.2090601@multiplay.co.uk> <20160411232416.d2906cf7287d98c9959926f6@dec.sakura.ne.jp> From: Steven Hartland Message-ID: <570BBD98.8060000@multiplay.co.uk> Date: Mon, 11 Apr 2016 16:07:04 +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: <20160411232416.d2906cf7287d98c9959926f6@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: Mon, 11 Apr 2016 15:07:04 -0000 On 11/04/2016 15:24, Tomoaki AOKI wrote: > Thanks for your answer! > > On Sun, 10 Apr 2016 16:15:56 +0100 > Steven Hartland wrote: > >> >> 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. > So now FreeBSD's ZFS defaults ashift 12, if I remember correctly, to > align datasets with 4k. ZFS calculates the most suitable given the reports physical and logical sector sizes, technically the default is ashift 9 unless altered by setting vfs.zfs.min_auto_ashift. > And UFS has minimum blocksize of 4k (defaults > 8k). And more, now gpart can align partitions as root specifies. > >>> 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. > So possibly some filesystems can be mis-aligned even if the start point > is properly aligned. > > *Mis-aligned fragments should be allowed, though. > >> 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. > Exactly. :-) > But there's large possibility of severe performance degradation caused > by mis-aligned blocks, especially in HDD, and the capacities of HDDs > became large, even in 2.5inch form factor. Defaulting block size to > physical sector size would be reasonable, if any option to downsize to > 512 bytes is provided. That would be a step back, correcting the offset would be the better fix. > *If I remember correctly, block size of UFS is 4096 bytes at minimum, > but supports 512 bytes fragments for small files (and to concentrate > tail portions of large files). It would be in many cases reasonable > trade-off, too. I don't use UFS so couldn't comment.