Date: Mon, 11 Apr 2016 16:07:04 +0100 From: Steven Hartland <killing@multiplay.co.uk> To: freebsd-current@freebsd.org Subject: Re: Question about cam 4K quirks Message-ID: <570BBD98.8060000@multiplay.co.uk> In-Reply-To: <20160411232416.d2906cf7287d98c9959926f6@dec.sakura.ne.jp> References: <20160410155621.82b751fa79f94ab2472264d7@dec.sakura.ne.jp> <CAOtMX2jXcQJv2VPR-j=aAgPWA_sJQ_TO7TfVpbmEmk6u9B1YYQ@mail.gmail.com> <20160410233510.2dd3c73b88f04aaf4b1b0ce6@dec.sakura.ne.jp> <570A6E2C.2090601@multiplay.co.uk> <20160411232416.d2906cf7287d98c9959926f6@dec.sakura.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/04/2016 15:24, Tomoaki AOKI wrote: > Thanks for your answer! > > On Sun, 10 Apr 2016 16:15:56 +0100 > Steven Hartland <killing@multiplay.co.uk> wrote: > >> >> On 10/04/2016 15:35, Tomoaki AOKI wrote: >>> On Sun, 10 Apr 2016 06:59:04 -0600 >>> Alan Somers <asomers@freebsd.org> wrote: >>> >>>> On Sun, Apr 10, 2016 at 12:56 AM, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> >>>> 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 <device>` 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?570BBD98.8060000>