Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Feb 2020 11:07:48 +0000
From:      Pete French <petefrench@ingresso.co.uk>
To:        freebsd-stable@freebsd.org
Subject:   Re: Running FreeBSD on M.2 SSD
Message-ID:  <6028c786-8610-01d9-818e-6f69a2fe9645@ingresso.co.uk>
In-Reply-To: <188F34DA-192C-4D44-96B5-18A7DAE8EC67@digsys.bg>
References:  <CAP4Gn9DFAoQtq6NP4hZ-Jq=ddnhp7Bzc_X%2BSce2FPVWn6kjASg@mail.gmail.com> <202002250115.01P1F9KX090465@mail.karels.net> <CAP4Gn9CqCSk5Lof_-05j1S0EWmTdB_HRfOe5zVig5khf7wJ0ow@mail.gmail.com> <188F34DA-192C-4D44-96B5-18A7DAE8EC67@digsys.bg>

next in thread | previous in thread | raw e-mail | index | archive | help


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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6028c786-8610-01d9-818e-6f69a2fe9645>