On Fri, 28 Feb 2020 21:44:45 -0300 Mario Olofo mario.ol...@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 = 12 and no errors after a lot of stress I put 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 completed. 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 are 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 às 13:18, Mario Olofo <mario.ol...@gmail.com> 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 às 12:52, Theron <theron.tar...@gmail.com> > 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 = 512 bytes >> > Tamanho de setor (lógico/físico): 512 bytes / 512 bytes >> > Tamanho E/S (mínimo/ótimo): 512 bytes / 512 bytes >> > Tipo de rótulo do disco: gpt >> > Identificador do disco: D1725E60-D734-4461-90F8-E9EB2376A65A >> > >> > Dispositivo Início Fim Setores Tamanho Tipo >> > /dev/sdb1 2048 1023999 1021952 499M Windows ambiente de >> > recuperação >> > /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ásico >> > /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 ZFS >> 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 person >> 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 flag >> > 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-unsubscr...@freebsd.org"
_______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
