JorgeB

From what I understand this works best when the SSD is mostly empty, still it should be able to sustain around 400/450MB/s even when the SLC cache is exhausted.

The larger models have more dies and can spread the writes in parallel, hence why they are faster, though I meant the 500GB models are the smallest capacity that can sustain 500GB/s, this for the Samsung 850 or 860EVO, the Crucial MX500 should be similar, around 400/450MB for the 500GB model, e.g. this is for the 850EVO, 860EVO is similar: https://www.anandtech.com/show/8747/samsung-ssd-850-evo-review/2 Turbowrite is the small SLC cache that lasts for a few seconds only, after that speed will decrease a lot for the smallest capacity models.

They can write up to 500MB/s, only when the SLC cache is empty, once that is exhausted speed are much slower, though I would still expect better then 100MB/s, but clearly they are what's limiting you're speed. IMO the MX500 and 860EVO are currently the best, though only the 1TB capacities can sustain 500MB/s writes.

The command redirects the log to that file, unfortunately don't see anything there crash related.

That explains it.

Is there nothing on taillog.txt?

Yes, not need to post, it will display the speeds in the end. It will reset at reboot, or type: sysctl vm.dirty_ratio=20 sysctl vm.dirty_background_ratio=10

That's one of the better ones, still it can't sustain 500MB/s, it can do around 400MB/s, are the SSDs being regularly trimmed? If yes test the actual write speeds with the script below, before testing lower the RAM cache to minimum by typing the below on the console to not interfere with the results: sysctl vm.dirty_ratio=2 sysctl vm.dirty_background_ratio=1 The copy the script to your flash drive and run the test with: /boot/write_speed_test.sh /mnt/cache/test.dat write_speed_test.sh

What model SSDs are you using? Sometimes people assume up to 500MB/s means 500MB/s sustained writes, very few SSDs are capable of that.

All the bz* files.

Try booting in safe mode.

See here: https://forums.unraid.net/topic/76070-unraid-os-version-666-available/?do=findComment&comment=702199

That's an SMR drive.

Not currently, but you can set all the other disks individually to lower values and set the global settings to the higher values.

Yep, same for me.

Then bad luck, I'm sure Seagate could cause bad sectors on a disk if they wanted to, I have a program that can create pending sectors on many disks, but for me it doesn't make any sense they doing that on purpose, at least not without a big warning on the disks "using this disk outside the USB enclosure will damage it" or most users would just think they got a bad disk, and that's not good for the brand.

That one shows problems in different attributes, like reported uncorrect and runtime bad block, in my mind further confirming nothing to do with being shucked, probably just bad luck, or you might have some issues on your server, like bad power, that can damage drives.

Looks to me just like a normal failing drive, don't see how it can be related to being shucked.

I'm not seing the repost on the UD thread, so will comment here. Dec 8 09:08:12 Highlander kernel: BTRFS info (device sda1): bdev /dev/sdb1 errs: wr 10554074, rd 11326465, flush 304, corrupt 81, gen 1 Device sdb on this pool dropped out at some point in the past, run a scrub but IMO bad idea to use a pool of USB devices, USB is very prone to disconnects and generally bad at reporting and handling errors.

Very strange, can you post a couple of those SMART reports?

Yes, that's normal, like you found just enter the current key and all will be fine.

Most likely Consider creating checksums for your files, very handy for situations like these.

I have this issue on most (if not all of my VMs), I just edit the XML when needed, but in case it helps to debug, here is for example my Windows 7 XML, and IIRC I never made any custom edit to this one, unlike the other VMs that have the SCSI controller with unmap enable. <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm'> <name>Windows 7</name> <uuid>f4c905e3-4e48-65a6-8c37-30c1c59d384b</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 7" icon="windows7.png" os="windows7"/> </metadata> <memory unit='KiB'>2097152</memory> <currentMemory unit='KiB'>2097152</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>1</vcpu> <cputune> <vcpupin vcpu='0' cpuset='1'/> </cputune> <os> <type arch='x86_64' machine='pc-i440fx-2.7'>hvm</type> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor_id state='on' value='none'/> </hyperv> </features> <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='1' threads='1'/> </cpu> <clock offset='localtime'> <timer name='hypervclock' present='yes'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/cache/VMs/Win7/vdisk1.img'/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/cache/isos/virtio-win-0.1.118-2.iso'/> <target dev='hdb' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'/> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:ad:ea:b3'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='pty'> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' websocket='-1' listen='0.0.0.0' keymap='en-us'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </memballoon> </devices> </domain>

See if upgrading Unraid to latest release helps.

And did you try a transfer using mc and realize that transferring disk to disk, even with turbo write will never have the same performance the same as transferring from outside the array? As for the unbalance instant speeds, they could be not that meaningful, since they can vary wildly, average speed in the end is what would be important, and if they are around 60/70MB/s they would be normal.