Running FreeBSD on M.2 SSD

[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
>
> Dispositivo    Início       Fim   Setores Tamanho Tipo
> /dev/sdb1        2048   1023999   1021952    499M Windows ambiente de
> recuperação
> /dev/sdb2     1024000   1228799    204800    100M Sistema EFI
> /dev/sdb3     1228800   1261567     32768     16M Microsoft reservado
> /dev/sdb4     1261568 532482047 531220480  253,3G Microsoft dados básico
> /dev/sdb5   532482048 549257215  16775168      8G FreeBSD ZFS
> /dev/sdb6   549257216 937719807 388462592  185,2G Linux sistema de arquivos
>
> The zfsroot was configured automatically by the installer, so I think that
> it align the volume automaticaly right?
>
> Mario

Yes, I don't see any potential alignment issue here.  I would wonder if 
this drive is misrepresenting its physical sector size, deceiving ZFS 
and the SATA driver into making small writes that the drive does not 
actually support, but it looks like you may have already tried the 
relevant workaround:

On 2020-02-27 23:44, Mario Olofo wrote:
> Maybe the problem really is a combination of factors, for the person that
> filed a bug on bugzilla the fix was setting the quirks 4k and broken_trim,
> but for me the real block size is 512bytes and only setting the flag
> broken_trim didn't help...
>
> Mario
Did you try 4k quirk ?

Theron