On 3/21/2024 8:46 AM, mike tancsa wrote:
summary: WD Blue 510 SSDs when attached to the mpr controller seem to
start throwing errors on random disks in the pools (see
https://lists.freebsd.org/archives/freebsd-hardware/2024-March/000100.html
for examples) after copying and destroying a zfs 20
summary: WD Blue 510 SSDs when attached to the mpr controller seem to
start throwing errors on random disks in the pools (see
https://lists.freebsd.org/archives/freebsd-hardware/2024-March/000100.html
for examples) after copying and destroying a zfs 200G dataset with many
small files 3 or 4
On 3/18/2024 4:59 AM, Christian Weisgerber wrote:
mike tancsa:
This might be more of a hardware question than anything, but I noticed the
drive is fairly fast on initial writes, but dramatically slows down over
time with a consistent write.
If I wait for 2min, it seems to be back to normal
Sou
mike tancsa:
> This might be more of a hardware question than anything, but I noticed the
> drive is fairly fast on initial writes, but dramatically slows down over
> time with a consistent write.
> If I wait for 2min, it seems to be back to normal
Sounds like normal behavior for a drive that ru
On 3/17/2024 4:32 AM, Andrea Venturoli wrote:
On 3/15/24 19:17, mike tancsa wrote:
(da5:mpr0:0:15:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on,
reset, or bus device reset occurred)
Hello.
I know I'm probably blaming the wrong component, but is your PSU up to
the task?
How many drives do
On 3/15/24 19:17, mike tancsa wrote:
(da5:mpr0:0:15:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset,
or bus device reset occurred)
Hello.
I know I'm probably blaming the wrong component, but is your PSU up to
the task?
How many drives do you have? Are they power-hungrier than the oth
On 3/15/2024 3:09 PM, Karl Denninger wrote:
I've got both the Kingston and Micron versions of these in production
use and have seen nothing like this at all; they get hit pretty hard
too, including release building (both direct and cross-builds) and
similar stuff.
What firmware are your devic
I've got both the Kingston and Micron versions of these in production
use and have seen nothing like this at all; they get hit pretty hard
too, including release building (both direct and cross-builds) and
similar stuff.
On 3/15/2024 2:17 PM, mike tancsa wrote:
On 3/14/2024 4:58 PM, Frank Leo
On 3/14/2024 4:58 PM, Frank Leonhardt wrote:
Sorry - not that deeply into modern SSD (never written a driver for one), but
based on my understanding your TRIM theory makes sense to me. I'd try turning
it off. It does seem to be an ongoing source of snafus.
I did use WD Blue SSDs but I suspect
Sorry - not that deeply into modern SSD (never written a driver for one), but
based on my understanding your TRIM theory makes sense to me. I'd try turning
it off. It does seem to be an ongoing source of snafus.
I did use WD Blue SSDs but I suspect they vary quite a bit. I've had rather too
man
On 3/14/2024 3:56 PM, mike tancsa wrote:
On 3/14/2024 3:48 PM, Frank Leonhardt wrote:
"CAM status: SCSI Status Error" suggests to me that the drive was
just too busy when asked. I'm not saying it's nothing to worry about,
but neither am I saying it is.
Given enough of them it does cause che
On 3/14/2024 3:48 PM, Frank Leonhardt wrote:
"CAM status: SCSI Status Error" suggests to me that the drive was just too busy
when asked. I'm not saying it's nothing to worry about, but neither am I saying it is.
Given enough of them it does cause checksum errors on the test pool
unfortunately
"CAM status: SCSI Status Error" suggests to me that the drive was just too busy
when asked. I'm not saying it's nothing to worry about, but neither am I saying
it is.
Flash storage is complicated. I doubt there's a huge cache in them, as as it
would be volatile it'd be a big no-no for synchronous writes. The OS could
cache it, of course. And if you're using ZFS then all bets are off. ZFS
guarantees (for POSIX) that a synchronous write goes to non volatile mem
On 3/14/2024 2:56 PM, Bob Bishop wrote:
Probably (I don’t know for sure) these drives have a RAM write cache
and really suck at committing from there to NVM.
ZFS doesnt seem to like it, or, possibly something else in addition
going on. I will start to get errors like this
(da4:mrsas0:0:2
Hi,
> On 14 Mar 2024, at 18:47, mike tancsa wrote:
>
> This might be more of a hardware question than anything, but I noticed the
> drive is fairly fast on initial writes, but dramatically slows down over time
> with a consistent write.
>
> At bootup time, I can blast out a file (UFS2 mount)
This might be more of a hardware question than anything, but I noticed
the drive is fairly fast on initial writes, but dramatically slows down
over time with a consistent write.
At bootup time, I can blast out a file (UFS2 mount)
# dd if=/dev/zero of=/mnt/tmp/junk.bin.`date "+%s"` bs=1m
stat
17 matches
Mail list logo
