From owner-freebsd-stable@freebsd.org Sat Feb 29 14:50:03 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 66A72260DE0 for ; Sat, 29 Feb 2020 14:50:03 +0000 (UTC) (envelope-from mario.olofo@gmail.com) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48V8T55k2xz4SbQ for ; Sat, 29 Feb 2020 14:50:01 +0000 (UTC) (envelope-from mario.olofo@gmail.com) Received: by mail-qt1-x82c.google.com with SMTP id e20so4312309qto.5 for ; Sat, 29 Feb 2020 06:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VfMiSCOZIym7cE7BJ25wANqglQY6s82lYeLWxLGD1RQ=; b=lObk1yRTl35uYhVS+fnybbx44St/Zx8nGKHbJ1qivfDITPtSqIeb0/CFkBPJhvs8WW kXvGraHSK/PTGUA3ddWa3cbkyH9txKXp3tG0UCtn+JSy20zyVehbXv4BDfEg5kIciQ6y yZX//Rwpu+9XaKTWyO/5isnqozwnTpcgl0fAVT+ZMBqqsNzGw+i6BCgcx0MfsPCdAjue xoHzsrFiwWtXwKDQroBP0Zau/DchYDKYgggHtEyhSNSXcR697oWasVY/Jw07qJJMNklZ uT5UM3ow66kM5feq+II7Wybv7S6wcJeXDFaFWNY11ZPJHM5sfWbL4/FhfbzhxKWjjssg Caqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VfMiSCOZIym7cE7BJ25wANqglQY6s82lYeLWxLGD1RQ=; b=CajpMLxqeS0SCEPHMqUAIUORatymBvcsl3+nWpna23GQ2fgNuRxEt+y+nJqskT3INz pSC/g/sNPz1jhYInWn1ap8zzlPuFQHhbHXWQ1+6WWgDIj9eXpPZ5sp2qZjQnzYbGZbwy 2hWdOhhB6jWc3uO8lGV7p92k2kW01MQESmaYsP47ol5rjwIA+4y5+XScys9m2NKQP4pl 1e2D2C7+r38SQSiC1QYNI3RanTpU7idnD2ki3/bLsHSB4B5hLJSUw3r9jp/lTGUQFXnO zbkLnkqnNEx/c02agc8sFqHjYJUXKeDkNsk2uiA6d7Gvjjy6N8logiTiriIyGCYpaQVM CIlQ== X-Gm-Message-State: APjAAAXFuVXAZieXik83LW3csV7GzZlvctzEkDz/bnDiMpeDxD+9gIHu Kt06gk/e+XlGZJ+VOoEWCLVRCbVkpw5CF5hY/e4nlg== X-Google-Smtp-Source: APXvYqw+TlKgzgSlSmaNOdtai3CSDJ313kS4nXvJr+rPwXqBLdB82vffwB7Nh6HllNLxir4VcVrD/H2qp+O2wAdh/Lc= X-Received: by 2002:ac8:4c89:: with SMTP id j9mr8838218qtv.29.1582987800528; Sat, 29 Feb 2020 06:50:00 -0800 (PST) MIME-Version: 1.0 References: <10e3153ee81dcd7919079cd0bfc16656@udns.ultimatedns.net> In-Reply-To: <10e3153ee81dcd7919079cd0bfc16656@udns.ultimatedns.net> From: Mario Olofo Date: Sat, 29 Feb 2020 11:49:48 -0300 Message-ID: Subject: Re: Running FreeBSD on M.2 SSD To: bsd-lists@bsdforge.com Cc: FreeBSD Stable X-Rspamd-Queue-Id: 48V8T55k2xz4SbQ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=lObk1yRT; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of marioolofo@gmail.com designates 2607:f8b0:4864:20::82c as permitted sender) smtp.mailfrom=marioolofo@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[c.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; IP_SCORE(0.00)[ip: (-9.20), ipnet: 2607:f8b0::/32(-1.88), asn: 15169(-1.67), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 14:50:03 -0000 Hello, sorry my lack of vocabulary and thanks for the clarification I think that it's a waste of space for me, and I'm afraid that this empty space is making the problem just less frequent. I remember that many years ago I implemented a FFS for an embedded system, and the SD Card was 4k "aligned", with the smallest block being 512 bytes. The only difference really is when I write/read from it, I have to align the command to request x blocks starting at some 4k aligned address, even if I just want 1 block. As the system had a lot of small files, I did the FFS on top of this as 1k sectors, I hoped that the ZFS could do something like that (ie. read/write every 4k but with 1k sectors). Mario Em s=C3=A1b., 29 de fev. de 2020 =C3=A0s 01:54, Chris escreveu: > On Fri, 28 Feb 2020 21:44:45 -0300 Mario Olofo mario.olofo@gmail.com said > > > Hello guys, a little update that let me more confused > > > > I reinstalled the FreeBSD with 4k pages using the sysctl > > vfs.zfs.min_auto_ashift =3D 12 and no errors after a lot of stress I pu= t on > > it. > > One thing that I noticed is that with the pool as 4k, the disk fill up > very > > fast, recompiling the kernel used my 8GB space and didn't even complete= d. > > But now I don't know if the 4k is the correct answer or if this just > delays > > the problem as the pages are bigger. > The TLDR of 4k vs 512 largely has to do with the size of the files going > onto your medium. Many files of a smaller size fit better on a 512 > boundary. > Whereas larger mp3s or archives fair better on a 4k boundary. BTW these a= re > called SECTOR sizes. Not pages. :) 4k blocks typically read faster, than > the > 512 blocks (sectors). Because more data can be consumed in one read/write= . > So really, your going to have to decide how best to "tune" your disk to > best > suite it's intended use. Many small files. Or big files, and storage. > > HTH > > --Chris > FreeBSD 14.0-FUTURE #0.000 cray256 > > > > Mario > > > > Em sex., 28 de fev. de 2020 =C3=A0s 13:18, Mario Olofo > > > escreveu: > > > > > Yes, tried 4k quirk but not on install because don't know how to, I > did a > > > clean install then patch and rebuild the kernel, but > > > the volume was already configured for 512bytes, I think I would need = to > > > create manually the volume, but don't remember how to anymore xD > > > But I'll search some tutorials and try. From what I saw, the patch > > > suggested on bugzilla got merged into the stable branch, so the quirk > will > > > be > > > detected to use 4k in the installer in a near future. > > > > > > Mario > > > > > > Em sex., 28 de fev. de 2020 =C3=A0s 12:52, Theron > > > escreveu: > > > > > >> On 2020-02-28 09:14, Mario Olofo wrote: > > >> > Thanks! > > >> > > > >> > The only thing that I didn't checked was the questions of Theron, > about > > >> > misaligned data. > > >> > The layout of the disk is as follows: > > >> > > > >> > Disco /dev/sdb: 447,1 GiB, 480113590272 bytes, 937721856 setores > > >> > Unidades: setor de 1 * 512 =3D 512 bytes > > >> > Tamanho de setor (l=C3=B3gico/f=C3=ADsico): 512 bytes / 512 bytes > > >> > Tamanho E/S (m=C3=ADnimo/=C3=B3timo): 512 bytes / 512 bytes > > >> > Tipo de r=C3=B3tulo do disco: gpt > > >> > Identificador do disco: D1725E60-D734-4461-90F8-E9EB2376A65A > > >> > > > >> > Dispositivo In=C3=ADcio Fim Setores Tamanho Tipo > > >> > /dev/sdb1 2048 1023999 1021952 499M Windows ambiente > de > > >> > recupera=C3=A7=C3=A3o > > >> > /dev/sdb2 1024000 1228799 204800 100M Sistema EFI > > >> > /dev/sdb3 1228800 1261567 32768 16M Microsoft > reservado > > >> > /dev/sdb4 1261568 532482047 531220480 253,3G Microsoft dados > b=C3=A1sico > > >> > /dev/sdb5 532482048 549257215 16775168 8G FreeBSD ZFS > > >> > /dev/sdb6 549257216 937719807 388462592 185,2G Linux sistema de > > >> arquivos > > >> > > > >> > The zfsroot was configured automatically by the installer, so I > think > > >> that > > >> > it align the volume automaticaly right? > > >> > > > >> > Mario > > >> > > >> Yes, I don't see any potential alignment issue here. I would wonder > if > > >> this drive is misrepresenting its physical sector size, deceiving ZF= S > > >> and the SATA driver into making small writes that the drive does not > > >> actually support, but it looks like you may have already tried the > > >> relevant workaround: > > >> > > >> On 2020-02-27 23:44, Mario Olofo wrote: > > >> > Maybe the problem really is a combination of factors, for the pers= on > > >> that > > >> > filed a bug on bugzilla the fix was setting the quirks 4k and > > >> broken_trim, > > >> > but for me the real block size is 512bytes and only setting the fl= ag > > >> > broken_trim didn't help... > > >> > > > >> > Mario > > >> Did you try 4k quirk ? > > >> > > >> Theron > > >> > > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g > " > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >