Re: Running FreeBSD on M.2 SSD

2020-02-28 Thread Chris

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

2020-02-28 Thread Mario Olofo
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

2020-02-28 Thread Mario Olofo
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

2020-02-28 Thread Theron

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

2020-02-28 Thread Mario Olofo
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"