Re: Running FreeBSD on M.2 SSD
Is TRIM still on? I understand the quirks patch indicates the drive has some trouble with 4K aligned writes. If memory serves it I also indicated broken TRIM so to be safe you need both. Daniel > On 29 Feb 2020, at 2:46, Mario Olofo wrote: > > 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. > > Mario > >> Em sex., 28 de fev. de 2020 às 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 às 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 = 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 DispositivoInício Fim Setores Tamanho Tipo /dev/sdb12048 1023999 1021952499M Windows ambiente de recuperação /dev/sdb2 1024000 1228799204800100M 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"
Re: Any sync-serial driver users (ce/cp/ctau/cx)?
On Sat, Feb 29, 2020, 1:18 PM Ed Maste wrote: > Is anyone using sync serial drivers ce, cp, ctau, or cx? NYCBUG's > dmesg didn't turn up any entries. I suspect these are obsolete and > ought to be removed. > These date from the 2000s. They were important for point to point links until maybe 2000 and largely obsolete by 2010 or so as internet connection technologies shifted away from sync T1/E1 lines to other technologies... These drivers replaced earlier ISA versions of the cards, see sys/i386/isa/cronyx.c for driver that also supported MSDOS! through at least stable/3. the cx driver dates from this time. The others date from later imports (2004-2006) by Roman Kurakin and are for the PCI generation of cards. Looking at the drivers themselves, we see that they haven't been updated, except for API changes, since maybe 2005 or 2006. The code was made MPSAFE at the time. However, several transitions in technology have happened in the network and tty layers and it's not clear this code works well with them. All the Giant code for network protocols and such was removed in 2007. And several other major changes since then. The ce driver has FreeBSD_version ifdefs from 3 to 7. None of the other drivers have such support. All of these drivers have mechanically obfuscated C code to implement their core functions (at least I hope it was done mechanically). Roman was the maintainer through 2006 or 2007. I think it was then handed off Murray Stokely around that time, then I think I got some number of cards around 2010 from him. We've been looking for a maintainer for these since then. There have been no takers. I'm unsure where these cards wound up in my collection, to be honest, but if there's serious interest I can look but I'm not hopeful I still have them as I've been purging all the stuff older than 10-15 years from my collection recently... Given the ~15 years of nothing but API changes to these cards, and the lack of testing of those changes, and the large technology transitions in net and tty layers of the system, I'd honestly be surprised if these drivers still work. Warner ___ > 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"
Any sync-serial driver users (ce/cp/ctau/cx)?
Is anyone using sync serial drivers ce, cp, ctau, or cx? NYCBUG's dmesg didn't turn up any entries. I suspect these are obsolete and ought to be removed. ___ 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"
Re: Running FreeBSD on M.2 SSD
On Fri, 28 Feb 2020, Chris wrote: 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. You're absolutely wrong. ZFS writes transaction groups, not files. Read something on ZFS, e.g. Handbook. A. ___ 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"
Re: Running FreeBSD on M.2 SSD
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áb., 29 de fev. de 2020 às 01:54, Chris escreveu: > 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 > > > 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 > > > 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 > > >> > > > >> > DispositivoInício Fim Setores Tamanho Tipo > > >> > /dev/sdb12048 1023999 1021952499M Windows ambiente > de > > >> > recuperação > > >> > /dev/sdb2 1024000 1228799204800100M 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 > " > >
