JorgeB

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.

Did you read the posts above? Also, it can vary with file size it's transferring, the smaller the average size, the lower the speed.

It does but since it weasn't working... Auto mode isn't implemented yet.

Turbo write won't perform so good when reading and writing to array at the same time, since one of the disks will need to alternate/seek between reads and writes, still 22MB/s seems slow, unbalance uses rsync and rsync is great but not well regarded for speed, try doing a copy with mc or Windows from one disk to another, I would expect speeds around 60MB/s, but like I said it will never get close to turbo writes from outside the array.

Dec 2 17:17:39 unRAID root: Found invalid GPT and valid MBR; converting MBR to GPT format Dec 2 17:17:39 unRAID root: in memory. Dec 2 17:17:39 unRAID root: *************************************************************** Dec 2 17:17:39 unRAID root: Dec 2 17:17:39 unRAID root: Warning: The kernel is still using the old partition table. Dec 2 17:17:39 unRAID root: The new table will be used at the next reboot or after you Dec 2 17:17:39 unRAID root: run partprobe(8) or kpartx(8) Just reboot and it will format.

Seagate won't be doing anything to make the disks reallocate sector on purpose, bad luck I guess.

And you might want to uninstall the plugin for now or it might override the manual change.