Re: Running FreeBSD on M.2 SSD
Hi Rebecca, I checked when I had the problem but the machine was up to date. I already solved this problem with the fix in the bugzilla and a lot of help from the great people here to try to narrow down the problem, but the little detail is that the installer wasn't using the ZFS volumes as 4k. So before the setup for partitions I entered the command line, loaded the ZFS driver and added the ashift=12 sysctl to it, so it installed the volumes as 4k, and after that I rebuilt the kernel with the patch (quirks = 0x03) =) Thank you, Mario Em ter., 10 de mar. de 2020 às 17:06, Rebecca Cran escreveu: > > >> On Feb 26, 2020, at 9:20 PM, Warner Losh wrote: > >> > >> On Wed, Feb 26, 2020, 8:54 PM Mario Olofo > wrote: > >> > >> Hello Mark, > >> Yes, I think that it's related to the WD Green SSD. > >> Today I found this bug on FreeBSD's bugzilla: > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225666 > >> Tried to reinstall and recompile the kernel with the patch but it didn't > >> work, I continue to see corrupted data. > >> I think that the only way to be really sure about the corrupted data is > to > >> reinstall again but already boot with the quirks configured, but the > >> kern.cam.ada.X.quirks don't seems to exists on FreeBSD 12, > >> so I have a probability of corruption between installation and > compilation > >> of the patched kernel... > >> Don't know what more to do... > > > > What happens if you disable TRIM? > > Also, have you checked to see if there’s a firmware update available? > > Rebecca > > ___ 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 Feb 26, 2020, at 9:20 PM, Warner Losh wrote: >> >> On Wed, Feb 26, 2020, 8:54 PM Mario Olofo wrote: >> >> Hello Mark, >> Yes, I think that it's related to the WD Green SSD. >> Today I found this bug on FreeBSD's bugzilla: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225666 >> Tried to reinstall and recompile the kernel with the patch but it didn't >> work, I continue to see corrupted data. >> I think that the only way to be really sure about the corrupted data is to >> reinstall again but already boot with the quirks configured, but the >> kern.cam.ada.X.quirks don't seems to exists on FreeBSD 12, >> so I have a probability of corruption between installation and compilation >> of the patched kernel... >> Don't know what more to do... > > What happens if you disable TRIM? Also, have you checked to see if there’s a firmware update available? Rebecca ___ 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
Yes, I installed with TRIM on and used the system with it on, but now I expanded the partition, reinstalled and rebuild the kernel with the quirk of broken TRIM to be safe but it appears to not be needed as far as I can tell. Will continue to work on the wifi driver now that the filesystem is stable =) Thank you all! <3 Mario Em dom., 1 de mar. de 2020 às 03:24, Daniel Kalchev escreveu: > 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 < > 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 > >> 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: 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: 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 > " > >
Re: Running FreeBSD on M.2 SSD
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" ___ 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 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"
Re: Running FreeBSD on M.2 SSD
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"
Re: Running FreeBSD on M.2 SSD
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"
Re: Running FreeBSD on M.2 SSD
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 Em sex., 28 de fev. de 2020 às 03:04, Pete Wright escreveu: > > > On 2020-02-27 20:44, Mario Olofo wrote: > > Thanks for the update. > > > > May you share what quirks was detected for your card and firmware to > > see if it matches mine? > > The only way I was able to run FreeBSD 12-STABLE on the SSD was using > > the suggested sysctl vfs.zfs.trim.enabled=0 > > 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... > > > This is a default install off of the latest 12.1-STABLE snapshot, no > special loader or sysctl knobs used. dmesg doesn't show anything > interesting: > > $ dmesg|grep ada > ses0: pass0,ada0 in 'Slot 00', SATA Slot: scbus0 target 0 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-2 ATA SATA 3.x device > ada0: Serial Number 185243800880 > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) > ada0: Command Queueing enabled > ada0: 457872MB (937721856 512 byte sectors) > GEOM_ELI: Device ada0p4.eli created. > > here's the output of sysctl: > $ sysctl kern.cam.ada > kern.cam.ada.0.sort_io_queue: 0 > kern.cam.ada.0.max_seq_zones: 0 > kern.cam.ada.0.optimal_nonseq_zones: 0 > kern.cam.ada.0.optimal_seq_zones: 0 > kern.cam.ada.0.zone_support: None > kern.cam.ada.0.zone_mode: Not Zoned > kern.cam.ada.0.rotating: 0 > kern.cam.ada.0.unmapped_io: 1 > kern.cam.ada.0.write_cache: -1 > kern.cam.ada.0.read_ahead: -1 > kern.cam.ada.0.delete_method: DSM_TRIM > kern.cam.ada.write_cache: 1 > kern.cam.ada.read_ahead: 1 > kern.cam.ada.spindown_suspend: 1 > kern.cam.ada.spindown_shutdown: 1 > kern.cam.ada.send_ordered: 1 > kern.cam.ada.default_timeout: 30 > kern.cam.ada.retry_count: 4 > > cheers, > -pete > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA > > ___ 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 2020-02-27 20:44, Mario Olofo wrote: Thanks for the update. May you share what quirks was detected for your card and firmware to see if it matches mine? The only way I was able to run FreeBSD 12-STABLE on the SSD was using the suggested sysctl vfs.zfs.trim.enabled=0 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... This is a default install off of the latest 12.1-STABLE snapshot, no special loader or sysctl knobs used. dmesg doesn't show anything interesting: $ dmesg|grep ada ses0: pass0,ada0 in 'Slot 00', SATA Slot: scbus0 target 0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number 185243800880 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada0: Command Queueing enabled ada0: 457872MB (937721856 512 byte sectors) GEOM_ELI: Device ada0p4.eli created. here's the output of sysctl: $ sysctl kern.cam.ada kern.cam.ada.0.sort_io_queue: 0 kern.cam.ada.0.max_seq_zones: 0 kern.cam.ada.0.optimal_nonseq_zones: 0 kern.cam.ada.0.optimal_seq_zones: 0 kern.cam.ada.0.zone_support: None kern.cam.ada.0.zone_mode: Not Zoned kern.cam.ada.0.rotating: 0 kern.cam.ada.0.unmapped_io: 1 kern.cam.ada.0.write_cache: -1 kern.cam.ada.0.read_ahead: -1 kern.cam.ada.0.delete_method: DSM_TRIM kern.cam.ada.write_cache: 1 kern.cam.ada.read_ahead: 1 kern.cam.ada.spindown_suspend: 1 kern.cam.ada.spindown_shutdown: 1 kern.cam.ada.send_ordered: 1 kern.cam.ada.default_timeout: 30 kern.cam.ada.retry_count: 4 cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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 Mario I am sorry, my comment contains no help for your case, but is treading my problems with FreeBSD in the past. Am Fr, 28.02.2020, 04:58 schrieb Pete Wright: >> root@~ # camcontrol devlist         at >> scbus0 target 0 lun 0 >> (ada0,pass0) >>  at scbus1 target 0 lun 0 (ada1,pass1) > just wanted to provide an update here. so i had a system that needed a new > root drive and > figured that the price of this device was worth a shot. i figured if it has > issues it'd be a > good opportunity to help find the root cause and fix them. so anyway...i > got the drive today and > i am not seeing any issues with it so far. here's the device on my end: > > so i don't think it's an issue with this specific m.2 device, perhaps there > is something odd > happening in your local env though that is causing this issue to crop up. The first Motherboard was an ASUS SP3G with FreeBSD 2.2.5, quriks in IO, depending on failures of the onBoard implementation of the SCSI-NCR, fixed by Stefan Esser. A few years later, my system crashes when compiling the world, sometimes after 30minutes, sometimes 32min... everytime on another place in the source... Reason was a fan for one of my two "hot" Seagate Barracudas, he won't spin anymore, he was "baken". My Powersupply was big, but if compiling, after the time, the baken fan empties the ELKOS of the Power and cause the reset... I've learned: FreeBSD is a great stable system, all my issues found the reason in other places in over 25years of using. OK, it seems, that it is a little bit intolerant to other issues or mad hardware :D... Bye Stefan ___ 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
Thanks for the update. May you share what quirks was detected for your card and firmware to see if it matches mine? The only way I was able to run FreeBSD 12-STABLE on the SSD was using the suggested sysctl vfs.zfs.trim.enabled=0 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 Em sex., 28 de fev. de 2020 às 00:58, Pete Wright escreveu: > > > On 2/24/20 11:13 AM, Mario Olofo wrote: > > Hi Pete, > > The nvmecontrol devlist don't found any devices. > pciconf -lv nvme0 didn't found anything either. > > The camcontrol devlist output was as follows: > > root@~ # camcontrol devlist > at scbus0 target 0 lun 0 (ada0,pass0) > at scbus1 target 0 lun 0 (ada1,pass1) > at scbus2 target 0 lun 0 (pass2,da0) > > > just wanted to provide an update here. so i had a system that needed a > new root drive and figured that the price of this device was worth a shot. > i figured if it has issues it'd be a good opportunity to help find the root > cause and fix them. so anyway...i got the drive today and i am not seeing > any issues with it so far. here's the device on my end: > > $ sudo camcontrol devlist > at scbus0 target 0 lun 0 (ada0,pass0) >at scbus2 target 0 lun 0 (ses0,pass1) > $ > > i am running 12-STABLE, with an encrypted zfsroot device. i've pumped > about 10gigs through it so far restoring my homedir with no issues, and zfs > scrub has run without any corrupted blocks detected. > > so i don't think it's an issue with this specific m.2 device, perhaps > there is something odd happening in your local env though that is causing > this issue to crop up. > > -pete > > -- > Pete wrightp...@nomadlogic.org > @nomadlogicLA > > ___ 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 2/24/20 11:13 AM, Mario Olofo wrote: Hi Pete, The nvmecontrol devlist don't found any devices. pciconf -lv nvme0 didn't found anything either. The camcontrol devlist output was as follows: root@~ # camcontrol devlist at scbus0 target 0 lun 0 (ada0,pass0) at scbus1 target 0 lun 0 (ada1,pass1) at scbus2 target 0 lun 0 (pass2,da0) just wanted to provide an update here. so i had a system that needed a new root drive and figured that the price of this device was worth a shot. i figured if it has issues it'd be a good opportunity to help find the root cause and fix them. so anyway...i got the drive today and i am not seeing any issues with it so far. here's the device on my end: $ sudo camcontrol devlist at scbus0 target 0 lun 0 (ada0,pass0) at scbus2 target 0 lun 0 (ses0,pass1) $ i am running 12-STABLE, with an encrypted zfsroot device. i've pumped about 10gigs through it so far restoring my homedir with no issues, and zfs scrub has run without any corrupted blocks detected. so i don't think it's an issue with this specific m.2 device, perhaps there is something odd happening in your local env though that is causing this issue to crop up. -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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 Daniel, Indeed setting the sysctl variable on install and after that on loader.conf appears to solve the data corruption problem =O Did the same as before, install git, node, npm, etc and all good. I will build the kernel and install xorg and xfce to use more disk space and see if some problem shows up Thank you, Mario Em qui., 27 de fev. de 2020 às 10:41, Daniel Kalchev escreveu: > Like I wrote earlier: > > sysctl vfs.zfs.trim.enabled=0 > > is your friend. > > Best to do this before installing and put vfs.zfs.trim.enabled=0 in > /boot/loader.conf in the boot drive to permanently have it. > > Daniel > > > On 27 Feb 2020, at 14:19, Mario Olofo wrote: > > > > This was supposed to be disabled by the quirk 0x02 > (ADA_Q_NCQ_TRIM_BROKEN) > > right? > > There's some command to disable trim on installer boot and then > permanently > > after the install? > > > > Mario > > > > > > ___ 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 2020-02-26 22:54, Mario Olofo wrote: Hello Mark, Yes, I think that it's related to the WD Green SSD. Today I found this bug on FreeBSD's bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225666 Tried to reinstall and recompile the kernel with the patch but it didn't work, I continue to see corrupted data. I think that the only way to be really sure about the corrupted data is to reinstall again but already boot with the quirks configured, but the kern.cam.ada.X.quirks don't seems to exists on FreeBSD 12, so I have a probability of corruption between installation and compilation of the patched kernel... Don't know what more to do... Mario Hi, please forgive my lack of experience with ZFS, but with regard to buggy SATA something hasn't been brought up yet: If ZFS is sitting on top of GPT, what sectorsize and offset are used? What blocksize is "native" to the drive? Are these aligned? I recall this chance for misalignment being a cause of silent write corruption after installing a new SSD for Apple MacOS; maybe FreeBSD ZFS on SATA happens to be similarly susceptible. 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"
Re: Running FreeBSD on M.2 SSD
This was supposed to be disabled by the quirk 0x02 (ADA_Q_NCQ_TRIM_BROKEN) right? There's some command to disable trim on installer boot and then permanently after the install? Mario Em qui., 27 de fev. de 2020 às 01:20, Warner Losh escreveu: > > > On Wed, Feb 26, 2020, 8:54 PM Mario Olofo wrote: > >> Hello Mark, >> >> Yes, I think that it's related to the WD Green SSD. >> Today I found this bug on FreeBSD's bugzilla: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225666 >> >> Tried to reinstall and recompile the kernel with the patch but it didn't >> work, I continue to see corrupted data. >> I think that the only way to be really sure about the corrupted data is to >> reinstall again but already boot with the quirks configured, but the >> kern.cam.ada.X.quirks don't seems to exists on FreeBSD 12, >> so I have a probability of corruption between installation and compilation >> of the patched kernel... >> >> Don't know what more to do... >> > > What happens if you disable TRIM? > > Warner > >> >> Mario >> >> Em qua., 26 de fev. de 2020 às 20:48, Mark Linimon >> escreveu: >> >> > On Tue, Feb 25, 2020 at 08:18:51PM -0300, Mario Olofo wrote: >> > > the ZFS already shows corrupted data... >> > >> > Although this may have already been stated in the thread and I missed >> it, >> > I have not had similar problems with the NVME chips I have used (first >> an >> > HP, and now a Samsung). I am really starting to wonder if this is >> > hardware- >> > specific. >> > >> > mcl >> > >> ___ >> 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: Running FreeBSD on M.2 SSD
On Wed, Feb 26, 2020, 8:54 PM Mario Olofo wrote: > Hello Mark, > > Yes, I think that it's related to the WD Green SSD. > Today I found this bug on FreeBSD's bugzilla: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225666 > > Tried to reinstall and recompile the kernel with the patch but it didn't > work, I continue to see corrupted data. > I think that the only way to be really sure about the corrupted data is to > reinstall again but already boot with the quirks configured, but the > kern.cam.ada.X.quirks don't seems to exists on FreeBSD 12, > so I have a probability of corruption between installation and compilation > of the patched kernel... > > Don't know what more to do... > What happens if you disable TRIM? Warner > > Mario > > Em qua., 26 de fev. de 2020 às 20:48, Mark Linimon > escreveu: > > > On Tue, Feb 25, 2020 at 08:18:51PM -0300, Mario Olofo wrote: > > > the ZFS already shows corrupted data... > > > > Although this may have already been stated in the thread and I missed it, > > I have not had similar problems with the NVME chips I have used (first an > > HP, and now a Samsung). I am really starting to wonder if this is > > hardware- > > specific. > > > > mcl > > > ___ > 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: Running FreeBSD on M.2 SSD
Hello Mark, Yes, I think that it's related to the WD Green SSD. Today I found this bug on FreeBSD's bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225666 Tried to reinstall and recompile the kernel with the patch but it didn't work, I continue to see corrupted data. I think that the only way to be really sure about the corrupted data is to reinstall again but already boot with the quirks configured, but the kern.cam.ada.X.quirks don't seems to exists on FreeBSD 12, so I have a probability of corruption between installation and compilation of the patched kernel... Don't know what more to do... Mario Em qua., 26 de fev. de 2020 às 20:48, Mark Linimon escreveu: > On Tue, Feb 25, 2020 at 08:18:51PM -0300, Mario Olofo wrote: > > the ZFS already shows corrupted data... > > Although this may have already been stated in the thread and I missed it, > I have not had similar problems with the NVME chips I have used (first an > HP, and now a Samsung). I am really starting to wonder if this is > hardware- > specific. > > mcl > ___ 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, I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux to test) and on my Hybrid HDD. Just configured and rc.conf to start my wifi dongle, downoaded git, node and npm via pkg and... as you can see in my screenshot, the ZFS already shows corrupted data... Can't been able to load the FreeBSD from the HDD though, don't know why, if someone direct me how to load the kernel from the HDD via loader or grub2, I'll try =) Em ter., 25 de fev. de 2020 às 18:56, Mario Olofo escreveu: > Hello, > > I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux to > test) and on my Hybrid HDD. > > Just configured and rc.conf to start my wifi dongle, downoaded git, node > and npm via pkg and... as you can see in my screenshot, > the ZFS already shows corrupted data... > > Can't been able to load the FreeBSD from the HDD though, don't know why, > if someone direct me how to load the > kernel from the HDD via loader or grub2, I'll try =) > > Mario > > Em ter., 25 de fev. de 2020 às 12:11, Karl Denninger > escreveu: > >> >> On 2/25/2020 9:53 AM, John Kennedy wrote: >> > On Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: >> >> I have often wondered if ZFS is more aggressive with discs, because >> until >> >> very recently any solid state drive I have used ZFS on broke very >> quicky. ... >> >I've always wondered if ZFS (and other snapshotting file systems) >> would help >> > kill SSD disks by locking up blocks longer than other filesystems >> might. For >> > example, I've got snapshot-backups going back, say, a year then those >> blocks >> > that haven't changed aren't going back into the pool to be rewritten >> (and >> > perhaps favored because of low write-cycle count). As the disk fills >> up, the >> > blocks that aren't locked up get reused more and more, leading to extra >> wear >> > on them. Eventually one of those will get to the point of erroring out. >> > >> >Personally, I just size generously but that isn't always an option >> for >> > everybody. >> >> I have a ZFS RaidZ2 on SSDs that has been running for several /years >> /without any problems. The drives are Intel 730s, which Intel CLAIMS >> don't have power-loss protection but in fact appear to; not only do they >> have caps in them but in addition they pass a "pull the cord out of the >> wall and then check to see if the data is corrupted on restart" test on >> a repeated basis, which I did several times before trusting them. >> >> BTW essentially all non-data-center SSDs fail that test and some fail it >> spectacularly (destroying the OS due to some of the in-flight data being >> comingled on an allocated block with something important; if the >> read/erase/write cycle interrupts you're cooked as the "other" data that >> was not being modified gets destroyed too!) -- the Intels are one of the >> very, very few that have passed it. >> >> -- >> -- Karl Denninger >> /The Market-Ticker/ >> S/MIME Email accepted and preferred >> > ___ 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, I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux to test) and on my Hybrid HDD. Just configured and rc.conf to start my wifi dongle, downoaded git, node and npm via pkg and... as you can see in my screenshot, the ZFS already shows corrupted data... Can't been able to load the FreeBSD from the HDD though, don't know why, if someone direct me how to load the kernel from the HDD via loader or grub2, I'll try =) Mario Em ter., 25 de fev. de 2020 às 12:11, Karl Denninger escreveu: > > On 2/25/2020 9:53 AM, John Kennedy wrote: > > On Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: > >> I have often wondered if ZFS is more aggressive with discs, because > until > >> very recently any solid state drive I have used ZFS on broke very > quicky. ... > >I've always wondered if ZFS (and other snapshotting file systems) > would help > > kill SSD disks by locking up blocks longer than other filesystems > might. For > > example, I've got snapshot-backups going back, say, a year then those > blocks > > that haven't changed aren't going back into the pool to be rewritten (and > > perhaps favored because of low write-cycle count). As the disk fills > up, the > > blocks that aren't locked up get reused more and more, leading to extra > wear > > on them. Eventually one of those will get to the point of erroring out. > > > >Personally, I just size generously but that isn't always an option for > > everybody. > > I have a ZFS RaidZ2 on SSDs that has been running for several /years > /without any problems. The drives are Intel 730s, which Intel CLAIMS > don't have power-loss protection but in fact appear to; not only do they > have caps in them but in addition they pass a "pull the cord out of the > wall and then check to see if the data is corrupted on restart" test on > a repeated basis, which I did several times before trusting them. > > BTW essentially all non-data-center SSDs fail that test and some fail it > spectacularly (destroying the OS due to some of the in-flight data being > comingled on an allocated block with something important; if the > read/erase/write cycle interrupts you're cooked as the "other" data that > was not being modified gets destroyed too!) -- the Intels are one of the > very, very few that have passed it. > > -- > -- Karl Denninger > /The Market-Ticker/ > S/MIME Email accepted and preferred > ___ 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
Guys, just a little update: I was able to boot from the HDD, just had to remove the FreeBSD partition from the SSD because the loader always load from the first pool that it founds (I say first because the two installations was on zfs/root, so it never boot the second pool). After one hour of usage the ZFS remains stable, no errors detected. I installed git, npm, node, xorg, xfce4, put some projects and loaded all the node_modules dependencies and after some time deleted some files, reboot twice, add and remove more files and the system have 0 errors... The problem with it on the SSD maybe really related to some lack of a very specific configuration of my part or is a driver parameter/misdetection problem =/ If you need more information from the system I can collect! Thank you all for the support, Mario Em ter., 25 de fev. de 2020 às 21:26, Mario Olofo escreveu: > Hybrid HDD are the norm for notebooks, that is, 1TB hard drive with 16GB > of SSD internal memory for fast writes and hot data (most used pages). > In my case, the notebook came with a ST1000LX015, but the problem happened > on the SSD, not on this HDD. > The SSD is a WD Green m.2, Rebecca already posted a link to the model: > https://shop.westerndigital.com/products/internal-drives/wd-green-sata-ssd#WDS480G2G0B > > Mario > > Em ter., 25 de fev. de 2020 às 21:12, George Michaelson > escreveu: > >> you said "hybrid HDD" >> >> is this possibly about write-back vs write-through cache integrity and >> some confusion in a driver over what is committed back in disk, and >> what is not? >> >> this feels like a very nasty corner case. Could you be explicit about >> versions and vendors? >> >> I am asking for selfish reasons: I have a lot of dependencies in a >> large SSD backed ZFS postgres server on Dell, and I am about to commit >> to a lenovo X1 Carbon 7/8th gen which would be SSD and almost >> certainly was intended to be ZFS-SSD in FreeBSD. >> >> -George >> >> On Wed, Feb 26, 2020 at 9:22 AM Mario Olofo >> wrote: >> > >> > Hello, >> > >> > I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux >> to >> > test) and on my Hybrid HDD. >> > >> > Just configured rc.conf to start my wifi dongle, downoaded git, node and >> > npm via pkg and... as you can see in my screenshot, >> > the ZFS already shows corrupted data... >> > >> > Can't been able to load the FreeBSD from the HDD though, don't know >> why, if >> > someone knows how to load the >> > kernel from the HDD via loader on SSD or grub2, I can try =) >> > >> > Mario >> > >> > Em ter., 25 de fev. de 2020 às 20:18, Mario Olofo < >> mario.ol...@gmail.com> >> > escreveu: >> > >> > > Hello, >> > > >> > > I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my >> Linux to >> > > test) and on my Hybrid HDD. >> > > >> > > Just configured and rc.conf to start my wifi dongle, downoaded git, >> node >> > > and npm via pkg and... as you can see in my screenshot, >> > > the ZFS already shows corrupted data... >> > > >> > > Can't been able to load the FreeBSD from the HDD though, don't know >> why, >> > > if someone direct me how to load the >> > > kernel from the HDD via loader or grub2, I'll try =) >> > > >> > > Em ter., 25 de fev. de 2020 às 18:56, Mario Olofo < >> mario.ol...@gmail.com> >> > > escreveu: >> > > >> > >> Hello, >> > >> >> > >> I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my >> Linux >> > >> to test) and on my Hybrid HDD. >> > >> >> > >> Just configured and rc.conf to start my wifi dongle, downoaded git, >> node >> > >> and npm via pkg and... as you can see in my screenshot, >> > >> the ZFS already shows corrupted data... >> > >> >> > >> Can't been able to load the FreeBSD from the HDD though, don't know >> why, >> > >> if someone direct me how to load the >> > >> kernel from the HDD via loader or grub2, I'll try =) >> > >> >> > >> Mario >> > >> >> > >> Em ter., 25 de fev. de 2020 às 12:11, Karl Denninger < >> k...@denninger.net> >> > >> escreveu: >> > >> >> > >>> >> > >>> On 2/25/2020 9:53 AM, John Kennedy wrote: >> > >>> > On Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: >> > >>> >> I have often wondered if ZFS is more aggressive with discs, >> because >> > >>> until >> > >>> >> very recently any solid state drive I have used ZFS on broke very >> > >>> quicky. ... >> > >>> >I've always wondered if ZFS (and other snapshotting file >> systems) >> > >>> would help >> > >>> > kill SSD disks by locking up blocks longer than other filesystems >> > >>> might. For >> > >>> > example, I've got snapshot-backups going back, say, a year then >> those >> > >>> blocks >> > >>> > that haven't changed aren't going back into the pool to be >> rewritten >> > >>> (and >> > >>> > perhaps favored because of low write-cycle count). As the disk >> fills >> > >>> up, the >> > >>> > blocks that aren't locked up get reused more and more, leading to >> > >>> extra wear >> > >>> > on them. Eventually one of those will get to the point of >> erroring
Re: Running FreeBSD on M.2 SSD
Hybrid HDD are the norm for notebooks, that is, 1TB hard drive with 16GB of SSD internal memory for fast writes and hot data (most used pages). In my case, the notebook came with a ST1000LX015, but the problem happened on the SSD, not on this HDD. The SSD is a WD Green m.2, Rebecca already posted a link to the model: https://shop.westerndigital.com/products/internal-drives/wd-green-sata-ssd#WDS480G2G0B Mario Em ter., 25 de fev. de 2020 às 21:12, George Michaelson escreveu: > you said "hybrid HDD" > > is this possibly about write-back vs write-through cache integrity and > some confusion in a driver over what is committed back in disk, and > what is not? > > this feels like a very nasty corner case. Could you be explicit about > versions and vendors? > > I am asking for selfish reasons: I have a lot of dependencies in a > large SSD backed ZFS postgres server on Dell, and I am about to commit > to a lenovo X1 Carbon 7/8th gen which would be SSD and almost > certainly was intended to be ZFS-SSD in FreeBSD. > > -George > > On Wed, Feb 26, 2020 at 9:22 AM Mario Olofo wrote: > > > > Hello, > > > > I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux > to > > test) and on my Hybrid HDD. > > > > Just configured rc.conf to start my wifi dongle, downoaded git, node and > > npm via pkg and... as you can see in my screenshot, > > the ZFS already shows corrupted data... > > > > Can't been able to load the FreeBSD from the HDD though, don't know why, > if > > someone knows how to load the > > kernel from the HDD via loader on SSD or grub2, I can try =) > > > > Mario > > > > Em ter., 25 de fev. de 2020 às 20:18, Mario Olofo > > > escreveu: > > > > > Hello, > > > > > > I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my > Linux to > > > test) and on my Hybrid HDD. > > > > > > Just configured and rc.conf to start my wifi dongle, downoaded git, > node > > > and npm via pkg and... as you can see in my screenshot, > > > the ZFS already shows corrupted data... > > > > > > Can't been able to load the FreeBSD from the HDD though, don't know > why, > > > if someone direct me how to load the > > > kernel from the HDD via loader or grub2, I'll try =) > > > > > > Em ter., 25 de fev. de 2020 às 18:56, Mario Olofo < > mario.ol...@gmail.com> > > > escreveu: > > > > > >> Hello, > > >> > > >> I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my > Linux > > >> to test) and on my Hybrid HDD. > > >> > > >> Just configured and rc.conf to start my wifi dongle, downoaded git, > node > > >> and npm via pkg and... as you can see in my screenshot, > > >> the ZFS already shows corrupted data... > > >> > > >> Can't been able to load the FreeBSD from the HDD though, don't know > why, > > >> if someone direct me how to load the > > >> kernel from the HDD via loader or grub2, I'll try =) > > >> > > >> Mario > > >> > > >> Em ter., 25 de fev. de 2020 às 12:11, Karl Denninger < > k...@denninger.net> > > >> escreveu: > > >> > > >>> > > >>> On 2/25/2020 9:53 AM, John Kennedy wrote: > > >>> > On Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: > > >>> >> I have often wondered if ZFS is more aggressive with discs, > because > > >>> until > > >>> >> very recently any solid state drive I have used ZFS on broke very > > >>> quicky. ... > > >>> >I've always wondered if ZFS (and other snapshotting file > systems) > > >>> would help > > >>> > kill SSD disks by locking up blocks longer than other filesystems > > >>> might. For > > >>> > example, I've got snapshot-backups going back, say, a year then > those > > >>> blocks > > >>> > that haven't changed aren't going back into the pool to be > rewritten > > >>> (and > > >>> > perhaps favored because of low write-cycle count). As the disk > fills > > >>> up, the > > >>> > blocks that aren't locked up get reused more and more, leading to > > >>> extra wear > > >>> > on them. Eventually one of those will get to the point of erroring > > >>> out. > > >>> > > > >>> >Personally, I just size generously but that isn't always an > option > > >>> for > > >>> > everybody. > > >>> > > >>> I have a ZFS RaidZ2 on SSDs that has been running for several /years > > >>> /without any problems. The drives are Intel 730s, which Intel CLAIMS > > >>> don't have power-loss protection but in fact appear to; not only do > they > > >>> have caps in them but in addition they pass a "pull the cord out of > the > > >>> wall and then check to see if the data is corrupted on restart" test > on > > >>> a repeated basis, which I did several times before trusting them. > > >>> > > >>> BTW essentially all non-data-center SSDs fail that test and some > fail it > > >>> spectacularly (destroying the OS due to some of the in-flight data > being > > >>> comingled on an allocated block with something important; if the > > >>> read/erase/write cycle interrupts you're cooked as the "other" data > that > > >>> was not being modified gets destroyed too!) -- the Intels are one of > the > >
Re: Running FreeBSD on M.2 SSD
you said "hybrid HDD" is this possibly about write-back vs write-through cache integrity and some confusion in a driver over what is committed back in disk, and what is not? this feels like a very nasty corner case. Could you be explicit about versions and vendors? I am asking for selfish reasons: I have a lot of dependencies in a large SSD backed ZFS postgres server on Dell, and I am about to commit to a lenovo X1 Carbon 7/8th gen which would be SSD and almost certainly was intended to be ZFS-SSD in FreeBSD. -George On Wed, Feb 26, 2020 at 9:22 AM Mario Olofo wrote: > > Hello, > > I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux to > test) and on my Hybrid HDD. > > Just configured rc.conf to start my wifi dongle, downoaded git, node and > npm via pkg and... as you can see in my screenshot, > the ZFS already shows corrupted data... > > Can't been able to load the FreeBSD from the HDD though, don't know why, if > someone knows how to load the > kernel from the HDD via loader on SSD or grub2, I can try =) > > Mario > > Em ter., 25 de fev. de 2020 às 20:18, Mario Olofo > escreveu: > > > Hello, > > > > I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux to > > test) and on my Hybrid HDD. > > > > Just configured and rc.conf to start my wifi dongle, downoaded git, node > > and npm via pkg and... as you can see in my screenshot, > > the ZFS already shows corrupted data... > > > > Can't been able to load the FreeBSD from the HDD though, don't know why, > > if someone direct me how to load the > > kernel from the HDD via loader or grub2, I'll try =) > > > > Em ter., 25 de fev. de 2020 às 18:56, Mario Olofo > > escreveu: > > > >> Hello, > >> > >> I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux > >> to test) and on my Hybrid HDD. > >> > >> Just configured and rc.conf to start my wifi dongle, downoaded git, node > >> and npm via pkg and... as you can see in my screenshot, > >> the ZFS already shows corrupted data... > >> > >> Can't been able to load the FreeBSD from the HDD though, don't know why, > >> if someone direct me how to load the > >> kernel from the HDD via loader or grub2, I'll try =) > >> > >> Mario > >> > >> Em ter., 25 de fev. de 2020 às 12:11, Karl Denninger > >> escreveu: > >> > >>> > >>> On 2/25/2020 9:53 AM, John Kennedy wrote: > >>> > On Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: > >>> >> I have often wondered if ZFS is more aggressive with discs, because > >>> until > >>> >> very recently any solid state drive I have used ZFS on broke very > >>> quicky. ... > >>> >I've always wondered if ZFS (and other snapshotting file systems) > >>> would help > >>> > kill SSD disks by locking up blocks longer than other filesystems > >>> might. For > >>> > example, I've got snapshot-backups going back, say, a year then those > >>> blocks > >>> > that haven't changed aren't going back into the pool to be rewritten > >>> (and > >>> > perhaps favored because of low write-cycle count). As the disk fills > >>> up, the > >>> > blocks that aren't locked up get reused more and more, leading to > >>> extra wear > >>> > on them. Eventually one of those will get to the point of erroring > >>> out. > >>> > > >>> >Personally, I just size generously but that isn't always an option > >>> for > >>> > everybody. > >>> > >>> I have a ZFS RaidZ2 on SSDs that has been running for several /years > >>> /without any problems. The drives are Intel 730s, which Intel CLAIMS > >>> don't have power-loss protection but in fact appear to; not only do they > >>> have caps in them but in addition they pass a "pull the cord out of the > >>> wall and then check to see if the data is corrupted on restart" test on > >>> a repeated basis, which I did several times before trusting them. > >>> > >>> BTW essentially all non-data-center SSDs fail that test and some fail it > >>> spectacularly (destroying the OS due to some of the in-flight data being > >>> comingled on an allocated block with something important; if the > >>> read/erase/write cycle interrupts you're cooked as the "other" data that > >>> was not being modified gets destroyed too!) -- the Intels are one of the > >>> very, very few that have passed it. > >>> > >>> -- > >>> -- Karl Denninger > >>> /The Market-Ticker/ > >>> S/MIME Email accepted and preferred > >>> > >> > ___ > 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: Running FreeBSD on M.2 SSD
Hello, I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux to test) and on my Hybrid HDD. Just configured rc.conf to start my wifi dongle, downoaded git, node and npm via pkg and... as you can see in my screenshot, the ZFS already shows corrupted data... Can't been able to load the FreeBSD from the HDD though, don't know why, if someone knows how to load the kernel from the HDD via loader on SSD or grub2, I can try =) Mario Em ter., 25 de fev. de 2020 às 20:18, Mario Olofo escreveu: > Hello, > > I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux to > test) and on my Hybrid HDD. > > Just configured and rc.conf to start my wifi dongle, downoaded git, node > and npm via pkg and... as you can see in my screenshot, > the ZFS already shows corrupted data... > > Can't been able to load the FreeBSD from the HDD though, don't know why, > if someone direct me how to load the > kernel from the HDD via loader or grub2, I'll try =) > > Em ter., 25 de fev. de 2020 às 18:56, Mario Olofo > escreveu: > >> Hello, >> >> I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux >> to test) and on my Hybrid HDD. >> >> Just configured and rc.conf to start my wifi dongle, downoaded git, node >> and npm via pkg and... as you can see in my screenshot, >> the ZFS already shows corrupted data... >> >> Can't been able to load the FreeBSD from the HDD though, don't know why, >> if someone direct me how to load the >> kernel from the HDD via loader or grub2, I'll try =) >> >> Mario >> >> Em ter., 25 de fev. de 2020 às 12:11, Karl Denninger >> escreveu: >> >>> >>> On 2/25/2020 9:53 AM, John Kennedy wrote: >>> > On Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: >>> >> I have often wondered if ZFS is more aggressive with discs, because >>> until >>> >> very recently any solid state drive I have used ZFS on broke very >>> quicky. ... >>> >I've always wondered if ZFS (and other snapshotting file systems) >>> would help >>> > kill SSD disks by locking up blocks longer than other filesystems >>> might. For >>> > example, I've got snapshot-backups going back, say, a year then those >>> blocks >>> > that haven't changed aren't going back into the pool to be rewritten >>> (and >>> > perhaps favored because of low write-cycle count). As the disk fills >>> up, the >>> > blocks that aren't locked up get reused more and more, leading to >>> extra wear >>> > on them. Eventually one of those will get to the point of erroring >>> out. >>> > >>> >Personally, I just size generously but that isn't always an option >>> for >>> > everybody. >>> >>> I have a ZFS RaidZ2 on SSDs that has been running for several /years >>> /without any problems. The drives are Intel 730s, which Intel CLAIMS >>> don't have power-loss protection but in fact appear to; not only do they >>> have caps in them but in addition they pass a "pull the cord out of the >>> wall and then check to see if the data is corrupted on restart" test on >>> a repeated basis, which I did several times before trusting them. >>> >>> BTW essentially all non-data-center SSDs fail that test and some fail it >>> spectacularly (destroying the OS due to some of the in-flight data being >>> comingled on an allocated block with something important; if the >>> read/erase/write cycle interrupts you're cooked as the "other" data that >>> was not being modified gets destroyed too!) -- the Intels are one of the >>> very, very few that have passed it. >>> >>> -- >>> -- Karl Denninger >>> /The Market-Ticker/ >>> S/MIME Email accepted and preferred >>> >> ___ 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 2/25/2020 9:53 AM, John Kennedy wrote: On Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: I have often wondered if ZFS is more aggressive with discs, because until very recently any solid state drive I have used ZFS on broke very quicky. ... I've always wondered if ZFS (and other snapshotting file systems) would help kill SSD disks by locking up blocks longer than other filesystems might. For example, I've got snapshot-backups going back, say, a year then those blocks that haven't changed aren't going back into the pool to be rewritten (and perhaps favored because of low write-cycle count). As the disk fills up, the blocks that aren't locked up get reused more and more, leading to extra wear on them. Eventually one of those will get to the point of erroring out. Personally, I just size generously but that isn't always an option for everybody. I have a ZFS RaidZ2 on SSDs that has been running for several /years /without any problems. The drives are Intel 730s, which Intel CLAIMS don't have power-loss protection but in fact appear to; not only do they have caps in them but in addition they pass a "pull the cord out of the wall and then check to see if the data is corrupted on restart" test on a repeated basis, which I did several times before trusting them. BTW essentially all non-data-center SSDs fail that test and some fail it spectacularly (destroying the OS due to some of the in-flight data being comingled on an allocated block with something important; if the read/erase/write cycle interrupts you're cooked as the "other" data that was not being modified gets destroyed too!) -- the Intels are one of the very, very few that have passed it. -- -- Karl Denninger /The Market-Ticker/ S/MIME Email accepted and preferred smime.p7s Description: S/MIME Cryptographic Signature
Re: Running FreeBSD on M.2 SSD
On Feb 25, 2020, at 9:03 AM, Daniel Kalchev wrote: > FreeBSD does not technically have driver for different disks. People asked > whether it is an NVMe device or SATA device, because those interfaces have > different drivers. > > But for FreeBSD, an mechanical SATA, hybrid SATA or SSD SATA will use exactly > the same SATA driver. It depends on the chipset. > > It is possible however, that the timing between the drive and the SATA > controller might be different and that is causing the problem. In a similar vein, I had an old MacBook Pro 2011 model. Its SATA chipset would negotiate SATA III speeds but any disk I/O at that speed would soon lead to widespread data corruption. SATA II drives and slower would be fine: no corruption. The funny thing was that this wasn't an issue when I used earlier versions of macOS: the problem only seemed to manifest when I "upgraded" to Mojave (IIRC). I surmised that maybe at that time period, whatever quirks or workarounds in the earlier OS versions no longer applied, and so whatever had caused the SATA III replacement drive to work (e.g., by force-negotiating at the slower speed) no longer did. :-( So, maybe a quirk/workaround that is in Linux and Windows but not in FreeBSD for you hardware *might* be a possibility? Cheers, Paul. ___ 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 Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: > I have often wondered if ZFS is more aggressive with discs, because until > very recently any solid state drive I have used ZFS on broke very quicky. ... I've always wondered if ZFS (and other snapshotting file systems) would help kill SSD disks by locking up blocks longer than other filesystems might. For example, I've got snapshot-backups going back, say, a year then those blocks that haven't changed aren't going back into the pool to be rewritten (and perhaps favored because of low write-cycle count). As the disk fills up, the blocks that aren't locked up get reused more and more, leading to extra wear on them. Eventually one of those will get to the point of erroring out. Personally, I just size generously but that isn't always an option for everybody. ___ 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
If my memory serves well, TRIM was originally not enabled by default on FreeBSD, because there were many drives that claimed to support it, but didn’t, or didn’t support it properly. That sort of is resolved today and WD Green is supposedly relatively recent drive. I am not aware of disabling TRIM creating any kind of problem for data consistency or drive longevity, except that it leads to slower writes, as the drive runs out of pre-erased blocks to write to. This is typically more pronounced on “cheaper” drives like this one where there is not much over-provisioning but much less pronounced on “server” drives that keep certain buffer capacity on the driv eunused for precisely that purpose. But why should a drive without TRIM wear more quickly? Daniel > On 25 Feb 2020, at 16:07, Pete French wrote: > > > > On 25/Feb/2020 13:28, Mario Olofo wrote: >> Good morning all, >> @Pete French, you have trim activated on your SSDs right? I heard that if >> its not activated, the SSD disc can stop working very quickly. > > On the curent dfives, yes, but I have run with trim disabled in the past, It > kinds of depends on the drive - so were horirbly slow on trim, and trim could > be a big bottleneck. Havent seen that on a recent drive though, and they all > now have trim enabled on them. > > ___ > 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: Running FreeBSD on M.2 SSD
On 25/Feb/2020 13:28, Mario Olofo wrote: Good morning all, @Pete French, you have trim activated on your SSDs right? I heard that if its not activated, the SSD disc can stop working very quickly. On the curent dfives, yes, but I have run with trim disabled in the past, It kinds of depends on the drive - so were horirbly slow on trim, and trim could be a big bottleneck. Havent seen that on a recent drive though, and they all now have trim enabled on them. ___ 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
FreeBSD does not technically have driver for different disks. People asked whether it is an NVMe device or SATA device, because those interfaces have different drivers. But for FreeBSD, an mechanical SATA, hybrid SATA or SSD SATA will use exactly the same SATA driver. It depends on the chipset. It is possible however, that the timing between the drive and the SATA controller might be different and that is causing the problem. Did you experiment with different settings of the SATA controller in BIOS? If the problem is related to the size of journal, that might mean for some reason the SSD is slow. About th eonly thing an SSD might be slow for is TRIM. Therefore, TRIM might be your problem if weirdly implemented in that drive … so you might try to disable it and see if the problem goes away. As it’s not a server, I doubt you will notice much of performance drop. You can disable TRIM for ZFS with sysctl vfs.zfs.trim.enabled=0 You can put it in /boot/loader.conf. Do this before writing any data to the pool or even creating the pool. Speaking of that, the output of sysctl kstat.zfs.misc.zio_trim might tell us something. I would advise doing all such tests with ZFS, because it will spot any flaky hardware/setup easily. Daniel > On 25 Feb 2020, at 15:28, Mario Olofo wrote: > > Good morning all, > > @Pete French, you have trim activated on your SSDs right? I heard that if > its not activated, the SSD disc can stop working very quickly. > @Daniel Kalchev, I used UFS2 with SU+J as suggested on the forums for me, > and in this case the filesystem didn't "corrupted", it justs kernel panic > from time to time so I gave up. > I think that the problem was related to the size of the journal, that > become full when I put so many files at once on the system, or was > deadlocks in the version of the OS that I was using. > @Alexander Leidinger I have the original HDD 1TB Hybrid that came with the > notebook will try to reinstall FreeBSD on it to see if it works correctly. > > Besides my notebook been a 2019 model Dell G3 with no customizations other > than the m.2 SSD, I never trust that the system is 100%, so I'll try all > possibilities. > 1- The BIOS received an update last month but I'll look if there's > something newer. > 2- Reinstall the FreeBSD on the Hybrid HDD, but if the problem is the > FreeBSD driver, it'll work correctly on that HD. > 3- Will try with other RAM. This I really don't think that is the problem > because is a brand new notebook, but... who knows =). > > Thank you, > > Mario > ___ 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 2/25/2020 8:28 AM, Mario Olofo wrote: Good morning all, @Pete French, you have trim activated on your SSDs right? I heard that if its not activated, the SSD disc can stop working very quickly. @Daniel Kalchev, I used UFS2 with SU+J as suggested on the forums for me, and in this case the filesystem didn't "corrupted", it justs kernel panic from time to time so I gave up. I think that the problem was related to the size of the journal, that become full when I put so many files at once on the system, or was deadlocks in the version of the OS that I was using. @Alexander Leidinger I have the original HDD 1TB Hybrid that came with the notebook will try to reinstall FreeBSD on it to see if it works correctly. Besides my notebook been a 2019 model Dell G3 with no customizations other than the m.2 SSD, I never trust that the system is 100%, so I'll try all possibilities. 1- The BIOS received an update last month but I'll look if there's something newer. 2- Reinstall the FreeBSD on the Hybrid HDD, but if the problem is the FreeBSD driver, it'll work correctly on that HD. 3- Will try with other RAM. This I really don't think that is the problem because is a brand new notebook, but... who knows =). Thank you, Mario I have a Lenovo Carbon X1 that has a Samsung nVME SSD in it and it's fine with both FreeBSD12-STABLE and Windows (I have it set up for dual EFI boot using REFIND.) It does not have a "custom" driver for Win10; it is using Microsoft's "built-in" stuff. Zero problems and I beat on it pretty-heavily. -- -- Karl Denninger /The Market-Ticker/ S/MIME Email accepted and preferred smime.p7s Description: S/MIME Cryptographic Signature
Re: Running FreeBSD on M.2 SSD
Good morning all, @Pete French, you have trim activated on your SSDs right? I heard that if its not activated, the SSD disc can stop working very quickly. @Daniel Kalchev, I used UFS2 with SU+J as suggested on the forums for me, and in this case the filesystem didn't "corrupted", it justs kernel panic from time to time so I gave up. I think that the problem was related to the size of the journal, that become full when I put so many files at once on the system, or was deadlocks in the version of the OS that I was using. @Alexander Leidinger I have the original HDD 1TB Hybrid that came with the notebook will try to reinstall FreeBSD on it to see if it works correctly. Besides my notebook been a 2019 model Dell G3 with no customizations other than the m.2 SSD, I never trust that the system is 100%, so I'll try all possibilities. 1- The BIOS received an update last month but I'll look if there's something newer. 2- Reinstall the FreeBSD on the Hybrid HDD, but if the problem is the FreeBSD driver, it'll work correctly on that HD. 3- Will try with other RAM. This I really don't think that is the problem because is a brand new notebook, but... who knows =). Thank you, Mario Em ter., 25 de fev. de 2020 às 08:08, Pete French escreveu: > > > On 25/Feb/2020 10:52, Daniel Kalchev wrote: > > It might well be, that FreeBSD is more agressive with your > motherboard/chipset or does not implement known quirk of that — which might > trigger some edge cases for the SSD. Ultimately, if you can move that SSD > to another motherboard and test it, it would confirm where the issue is. > > I have often wondered if ZFS is more aggressive with discs, because > until very recently any solid state drive I have used ZFS on broke very > quicky. For USB sticks that is not unexpected, but decent SSD's also > seem to last less than a year with ZFS on top. I don't let it bother me > anymore simply always install them in pairs and replace when I start > seeing errors. > > By the way, I am not talking about checksum errors here from ZFS, I am > talking about the drive starting to error into dmesg. Checksum errors I > could belive that I was gettign with UFS in the past and just didnt know > it. But this behaviour is that the drive stops working. Some USB sticks > lasted less than a week. Some earlier SSD's only a month or two. More > recent SSD's are lasting longer, and I dont use USB sticks much anymore. > > I am sure I have mentioned this before and people say that it works for > them, so maybe its my magic touch which causes it. :-) > > -pete. > ___ > 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: Running FreeBSD on M.2 SSD
On 25/Feb/2020 10:52, Daniel Kalchev wrote: It might well be, that FreeBSD is more agressive with your motherboard/chipset or does not implement known quirk of that — which might trigger some edge cases for the SSD. Ultimately, if you can move that SSD to another motherboard and test it, it would confirm where the issue is. I have often wondered if ZFS is more aggressive with discs, because until very recently any solid state drive I have used ZFS on broke very quicky. For USB sticks that is not unexpected, but decent SSD's also seem to last less than a year with ZFS on top. I don't let it bother me anymore simply always install them in pairs and replace when I start seeing errors. By the way, I am not talking about checksum errors here from ZFS, I am talking about the drive starting to error into dmesg. Checksum errors I could belive that I was gettign with UFS in the past and just didnt know it. But this behaviour is that the drive stops working. Some USB sticks lasted less than a week. Some earlier SSD's only a month or two. More recent SSD's are lasting longer, and I dont use USB sticks much anymore. I am sure I have mentioned this before and people say that it works for them, so maybe its my magic touch which causes it. :-) -pete. ___ 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
I have had disks, that work “perfectly" under UFS and various RAID controllers (and DOS and Windows), but always reported checksum errors when running under ZFS. It would happen on any motherboard or controller. That made me never use anything but ZFS on data that I cannot recreate 100%, fast… but that is separate story. I labeled those disks bad and they sit in my “museum”. Needless to say some were brand new. Not saying you have this issue, but sharing anecdotal evidence. But I wonder how you discovered you had corruption with UFS? What is observed? It might well be, that FreeBSD is more agressive with your motherboard/chipset or does not implement known quirk of that — which might trigger some edge cases for the SSD. Ultimately, if you can move that SSD to another motherboard and test it, it would confirm where the issue is. Daniel > On 25 Feb 2020, at 3:35, Mario Olofo wrote: > > Hi Mike, thanks for the insight. > > I tried both, but not at the same time. > When I found that the ZFS was corrupting the filesystem, I reinstalled the > FreeBSD using UFS but no luck. > Ulf told me that he had the same problem and it turned out the problem was > a defective RAM, but here I just ran the test 2 times, > one from Dell BIOS Diagnostics Tool and other from mdsched.exe from Windos > 10, but here the RAM is ok... > > Thank you again, > > Mario > ___ 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
Hi, > On 25 Feb 2020, at 01:35, Mario Olofo wrote: > > Hi Mike, thanks for the insight. > > I tried both, but not at the same time. > When I found that the ZFS was corrupting the filesystem, I reinstalled the > FreeBSD using UFS but no luck. > Ulf told me that he had the same problem and it turned out the problem was > a defective RAM, but here I just ran the test 2 times, > one from Dell BIOS Diagnostics Tool and other from mdsched.exe from Windos > 10, but here the RAM is ok… Software tests will not always find marginally faulty RAM. If you can, try swapping for known good RAM; or if you have lots of RAM installed, try taking half the RAM out at a time and see if that affects stability. > Thank you again, > > Mario > > Em seg., 24 de fev. de 2020 às 22:15, Mike Karels > escreveu: > [etc] -- Bob Bishop r...@gid.co.uk ___ 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
Hi Mike, thanks for the insight. I tried both, but not at the same time. When I found that the ZFS was corrupting the filesystem, I reinstalled the FreeBSD using UFS but no luck. Ulf told me that he had the same problem and it turned out the problem was a defective RAM, but here I just ran the test 2 times, one from Dell BIOS Diagnostics Tool and other from mdsched.exe from Windos 10, but here the RAM is ok... Thank you again, Mario Em seg., 24 de fev. de 2020 às 22:15, Mike Karels escreveu: > Mario, have you ruled out the possibility that the UFS and ZFS filesystems > are overlapping? It would be worth a careful check of the partition table > and filesystem sizes. You can check the actual UFS size with dumpfs. > I ask in part because UFS has a tendency to write to the last cylinder > group. > > Also, are you sure you want to use both UFS and ZFS? I do it personally > for historical reasons, but on a larger machine with several disks. But > there are reasons not to use both, including different memory cache > strategies. > > Mike > ___ 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
Mario, have you ruled out the possibility that the UFS and ZFS filesystems are overlapping? It would be worth a careful check of the partition table and filesystem sizes. You can check the actual UFS size with dumpfs. I ask in part because UFS has a tendency to write to the last cylinder group. Also, are you sure you want to use both UFS and ZFS? I do it personally for historical reasons, but on a larger machine with several disks. But there are reasons not to use both, including different memory cache strategies. Mike ___ 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 Mon, Feb 24, 2020 at 3:56 PM Mario Olofo wrote: > Hi Matt, > > The ext4 don't have data checksum, but have metadata checksum, which would > probably be corrupted as well, as I reinstalled my Linux over the same > partition the FreeBSD was using, and by > now I have a lot more files on it than I had on FreeBSD. > Mario, Thanks for that clarification; since not all distros necessarily have it based on recency, etc., I didn’t want to assume metadata_csum was enabled, but that’s a positive start. Not as thorough as full data checksumming, but you’re probably right that it’s at least a good baseline to make reasonable judgments about with regard to heavy ext4 use on the same drive. Thanks, — Matt ___ 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
Hi Matt, The ext4 don't have data checksum, but have metadata checksum, which would probably be corrupted as well, as I reinstalled my Linux over the same partition the FreeBSD was using, and by now I have a lot more files on it than I had on FreeBSD. If you look at the forum post I created, you'll see that I ran the command smartctl as well, and it shows that there's no problem with the SSD, it's a new SDD, some months of use. I ran the command inside FreeBSD: === START OF INFORMATION SECTION === Model Family: WD Blue and Green SSDs Device Model: WDC WDS480G2G0B-00EPW0 Serial Number:183541800480 LU WWN Device Id: 5 001b44 8b9628e44 Firmware Version: UK45 User Capacity:480.113.590.272 bytes [480 GB] Sector Size: 512 bytes logical/physical Rotation Rate:Solid State Device Form Factor: M.2 Device is:In smartctl database [for details use: -P show] ATA Version is: ACS-2 T13/2015-D revision 3 SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is:Mon Sep 2 12:34:29 2019 -03 SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 32) The self-test routine was interrupted by the host with a hard or soft reset. Total time to complete Offline data collection:( 120) seconds. Offline data collection capabilities:(0x15) SMART execute Offline immediate. No Auto Offline data collection support. Abort Offline collection upon new command. No Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. No Selective Self-test supported. SMART capabilities:(0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability:(0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time:( 2) minutes. Extended self-test routine recommended polling time:( 85) minutes. SMART Attributes Data Structure revision number: 1 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0032 100 100 000Old_age Always - 0 9 Power_On_Hours 0x0032 100 100 000Old_age Always - 3281 12 Power_Cycle_Count 0x0032 100 100 000Old_age Always - 570 165 Block_Erase_Count 0x0032 100 100 000Old_age Always - 1025 166 Minimum_PE_Cycles_TLC 0x0032 100 100 ---Old_age Always - 7 167 Max_Bad_Blocks_per_Die 0x0032 100 100 ---Old_age Always - 0 168 Maximum_PE_Cycles_TLC 0x0032 100 100 ---Old_age Always - 15 169 Total_Bad_Blocks0x0032 100 100 ---Old_age Always - 204 170 Grown_Bad_Blocks0x0032 100 100 ---Old_age Always - 0 171 Program_Fail_Count 0x0032 100 100 000Old_age Always - 0 172 Erase_Fail_Count0x0032 100 100 000Old_age Always - 0 173 Average_PE_Cycles_TLC 0x0032 100 100 000Old_age Always - 7 174 Unexpected_Power_Loss 0x0032 100 100 000Old_age Always - 112 184 End-to-End_Error0x0032 100 100 ---Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000Old_age Always - 2 188 Command_Timeout 0x0032 100 100 ---Old_age Always - 0 194 Temperature_Celsius 0x0022 063 053 000Old_age Always - 37 (Min/Max 6/53) 199 UDMA_CRC_Error_Count0x0032 100 100 ---Old_age Always - 0 230 Media_Wearout_Indicator 0x0032 100 100 000Old_age Always - 0x025c0128025c 232 Available_Reservd_Space 0x0033 100 100 005Pre-fail Always - 100 233 NAND_GB_Written_TLC 0x0032 100 100 ---Old_age Always - 3227 234 NAND_GB_Written_SLC 0x0032 100 100 000Old_age Always - 11545 241 Total_Host_GB_Written 0x0030 100 100 000
Re: Running FreeBSD on M.2 SSD
On Mon, Feb 24, 2020 at 2:44 PM Mario Olofo wrote: > Hi Pete, in the logs there's nothing wrong, I only see the problem on zpool > status after the first scrub, even if I just > reinstall the FreeBSD and some basic packages (didn't even need a lot of > files as I thought). Mario, Out of curiosity, how are you able to tell for sure you aren’t also experiencing corruption under Linux or Windows on the same hardware? Have you been able to run a ZFS scrub using ZFS on Linux? Both default file systems, ext4 and NTFS, are completely unable of letting you know if corruption has occurred — they’ll just corrupt silently — so I’m wondering how you’ve ruled that out. Thanks, — Matt ___ 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
Hi Pete, in the logs there's nothing wrong, I only see the problem on zpool status after the first scrub, even if I just reinstall the FreeBSD and some basic packages (didn't even need a lot of files as I thought). Hello Rebecca, indeed is this model I'm using, the SATA versions is cheaper so I installed this. My notebook is a Dell G3 i5 8th gen, the original disk is the hybrid HDD detected as ST1000LX015. Mario Em seg., 24 de fev. de 2020 às 16:36, Rebecca Cran escreveu: > On 2/24/20 12:13 PM, Mario Olofo wrote: > > > root@~ # camcontrol devlist > > at scbus0 target 0 lun 0 (ada0,pass0) > > at scbus1 target 0 lun 0 (ada1,pass1) > > at scbus2 target 0 lun 0 (pass2,da0) > > Ok, so it's a SATA M.2 SSD - one of these: > > https://shop.westerndigital.com/products/internal-drives/wd-green-sata-ssd#WDS480G2G0B > > > -- > Rebecca Cran > > > ___ 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 2/24/20 12:13 PM, Mario Olofo wrote: root@~ # camcontrol devlist at scbus0 target 0 lun 0 (ada0,pass0) at scbus1 target 0 lun 0 (ada1,pass1) at scbus2 target 0 lun 0 (pass2,da0) Ok, so it's a SATA M.2 SSD - one of these: https://shop.westerndigital.com/products/internal-drives/wd-green-sata-ssd#WDS480G2G0B -- Rebecca Cran ___ 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 2020-02-24 11:13, Mario Olofo wrote: Hi Pete, The nvmecontrol devlist don't found any devices. pciconf -lv nvme0 didn't found anything either. The camcontrol devlist output was as follows: root@~ # camcontrol devlist at scbus0 target 0 lun 0 (ada0,pass0) at scbus1 target 0 lun 0 (ada1,pass1) at scbus2 target 0 lun 0 (pass2,da0) The dmesg | grep ada1 shows the following: Feb 24 18:54:31 kernel: ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 Feb 24 18:54:31 kernel: ada1: ACS-2 ATA SATA 3.x device Feb 24 18:54:31 kernel: ada1: Serial Number 183541800480 Feb 24 18:54:31 kernel: ada1: 600.00MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) Feb 24 18:54:31 kernel: ada1: Command Queueing enabled Feb 24 18:54:31 kernel: ada1:457872MB (937721856 512 byte sectors) Mario Thanks Mario, When you run into issues or filesystem corruption do you see anything in the dmesg buffer or in /var/log/messages? -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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
Hi Pete, The nvmecontrol devlist don't found any devices. pciconf -lv nvme0 didn't found anything either. The camcontrol devlist output was as follows: root@~ # camcontrol devlist at scbus0 target 0 lun 0 (ada0,pass0) at scbus1 target 0 lun 0 (ada1,pass1) at scbus2 target 0 lun 0 (pass2,da0) The dmesg | grep ada1 shows the following: Feb 24 18:54:31 kernel: ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 Feb 24 18:54:31 kernel: ada1: ACS-2 ATA SATA 3.x device Feb 24 18:54:31 kernel: ada1: Serial Number 183541800480 Feb 24 18:54:31 kernel: ada1: 600.00MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) Feb 24 18:54:31 kernel: ada1: Command Queueing enabled Feb 24 18:54:31 kernel: ada1:457872MB (937721856 512 byte sectors) Mario Em seg., 24 de fev. de 2020 às 15:27, Pete Wright escreveu: > > > On 2020-02-24 09:58, Mario Olofo wrote: > > Hello John, thank you for your reply. > > > > Yesterday I reinstalled the 12.1 on a VirtualBox virtual machine, did the > > same steps and it didn't corrupted the ZFS, so I think that the problem > is > > in the FreeBSD's driver for m.2 SSD. > > Besides the corruption of the filesystem, I forgot to mention that I > > noticed a little noise on disk writes on FreeBSD, but not on Linux or > > Windows. > > I found some old threads about incorrectly params for sector size for > > Samsung's SSD, but nothing about WD. > > If someone responsible for the driver need help to solve this problem, I > > can reinstall the FreeBSD on my machine and compile a custom kernel to > > gather debug information. > > Unfortunately you haven't provided much in details regarding the > hardware you are running as far as FreeBSD see's it. I can confirm I > have had many systems using m.2 for quite a while and have had zero > issues. Could you provide some of these details? > > (assuming this is an NVMe device): > $ sudo nvmecontrol devlist > $ sudo pciconf -lv nvme0 > > if your device isn't NVMe and is a sata device then this info may be > helpful as well: > $ sudo camcontrol devlist > > and your dmesg will also probably be helpful here as well. I think > getting at least this basic info will help determine where the issue is > cropping up. > > cheers, > -pete > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA > > ___ 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 2020-02-24 09:58, Mario Olofo wrote: Hello John, thank you for your reply. Yesterday I reinstalled the 12.1 on a VirtualBox virtual machine, did the same steps and it didn't corrupted the ZFS, so I think that the problem is in the FreeBSD's driver for m.2 SSD. Besides the corruption of the filesystem, I forgot to mention that I noticed a little noise on disk writes on FreeBSD, but not on Linux or Windows. I found some old threads about incorrectly params for sector size for Samsung's SSD, but nothing about WD. If someone responsible for the driver need help to solve this problem, I can reinstall the FreeBSD on my machine and compile a custom kernel to gather debug information. Unfortunately you haven't provided much in details regarding the hardware you are running as far as FreeBSD see's it. I can confirm I have had many systems using m.2 for quite a while and have had zero issues. Could you provide some of these details? (assuming this is an NVMe device): $ sudo nvmecontrol devlist $ sudo pciconf -lv nvme0 if your device isn't NVMe and is a sata device then this info may be helpful as well: $ sudo camcontrol devlist and your dmesg will also probably be helpful here as well. I think getting at least this basic info will help determine where the issue is cropping up. cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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 John, thank you for your reply. Yesterday I reinstalled the 12.1 on a VirtualBox virtual machine, did the same steps and it didn't corrupted the ZFS, so I think that the problem is in the FreeBSD's driver for m.2 SSD. Besides the corruption of the filesystem, I forgot to mention that I noticed a little noise on disk writes on FreeBSD, but not on Linux or Windows. I found some old threads about incorrectly params for sector size for Samsung's SSD, but nothing about WD. If someone responsible for the driver need help to solve this problem, I can reinstall the FreeBSD on my machine and compile a custom kernel to gather debug information. Thank you, Mario Em seg., 24 de fev. de 2020 às 11:47, John Kennedy escreveu: > On Sun, Feb 23, 2020 at 11:18:08PM -0300, Mario Olofo wrote: > > Some time ago I tried to switch from Linux to FreeBSD 12.1, used a WiFi > > dongle and all good, until I found that both ZFS and UFS corrupted the > > filesystem very fast. > > I work with a lot of small files because of web programming > (node_modules), > > so after a clean install, after installing the dependencies for my > project, > > if I scrub the zpool, it always found that the system is corrupted and > > never recover. > > > > I have a WD Green M.2 SSD 480GB WDS480G2G0B. > > Both Linux and Windows work correctly and don't detect any problems with > > the disk. > > > > Did someone knows if it isn't supported by FreeBSD or there's some > specific > > configuration params that I need to set to it work correctly? > > > > I made a post on the forums back in the day I had the problem, the logs I > > had are all there: > > > https://forums.freebsd.org/threads/fixing-metadata-errors-after-zfs-clear-zfs-scrub.72139/ > > > Can't answer your WD Green question specifically, but I'm happy with my > setup, below. Good to look for quirks, but you probably also want to list > other hardware involved as well (which might have it's own quirks). If > you've > had good success (and no corruption) with two other operating systems on > the > same hardware, I'd probably be looking at software and/or drivers, and that > requires knowledge of the hardware. > > > I've got dual EVOs (below is just from one I'm typing on) on two > different > FreeBSD boxes. Nothing specific I had to do in FreeBSD, although on the > other > motherboard I had to tweak the motherboard settings to give it the > channels it > needed to shine. > > kernel: nvd0: NVMe namespace > kernel: nvd0: 476940MB (976773168 512 byte sectors) > kernel: nvd1: NVMe namespace > kernel: nvd1: 476940MB (976773168 512 byte sectors) > > If compiling kernel and packages from source count as having lots of > little > files, then I do as well. I think I'm ZFS everywhere (boot partition being > the question over time). > > Personally, the only ZFS corruption I've had over time has been caused by > bad hardware. When I moved the disks to another box, they were fine with > the same version of FreeBSD. I scrub my zpool about once a month just > because, > plus after I get the kernel to crash. > > The original box went all the way back to root-on-ZFS + FreeBSD 11. The > newer box just started around 12.0 (2019-05-31). > ___ > 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: Running FreeBSD on M.2 SSD
On Sun, Feb 23, 2020 at 11:18:08PM -0300, Mario Olofo wrote: > Some time ago I tried to switch from Linux to FreeBSD 12.1, used a WiFi > dongle and all good, until I found that both ZFS and UFS corrupted the > filesystem very fast. > I work with a lot of small files because of web programming (node_modules), > so after a clean install, after installing the dependencies for my project, > if I scrub the zpool, it always found that the system is corrupted and > never recover. > > I have a WD Green M.2 SSD 480GB WDS480G2G0B. > Both Linux and Windows work correctly and don't detect any problems with > the disk. > > Did someone knows if it isn't supported by FreeBSD or there's some specific > configuration params that I need to set to it work correctly? > > I made a post on the forums back in the day I had the problem, the logs I > had are all there: > https://forums.freebsd.org/threads/fixing-metadata-errors-after-zfs-clear-zfs-scrub.72139/ Can't answer your WD Green question specifically, but I'm happy with my setup, below. Good to look for quirks, but you probably also want to list other hardware involved as well (which might have it's own quirks). If you've had good success (and no corruption) with two other operating systems on the same hardware, I'd probably be looking at software and/or drivers, and that requires knowledge of the hardware. I've got dual EVOs (below is just from one I'm typing on) on two different FreeBSD boxes. Nothing specific I had to do in FreeBSD, although on the other motherboard I had to tweak the motherboard settings to give it the channels it needed to shine. kernel: nvd0: NVMe namespace kernel: nvd0: 476940MB (976773168 512 byte sectors) kernel: nvd1: NVMe namespace kernel: nvd1: 476940MB (976773168 512 byte sectors) If compiling kernel and packages from source count as having lots of little files, then I do as well. I think I'm ZFS everywhere (boot partition being the question over time). Personally, the only ZFS corruption I've had over time has been caused by bad hardware. When I moved the disks to another box, they were fine with the same version of FreeBSD. I scrub my zpool about once a month just because, plus after I get the kernel to crash. The original box went all the way back to root-on-ZFS + FreeBSD 11. The newer box just started around 12.0 (2019-05-31). ___ 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"
