JorgeB

These new disks are reportedly shingled as well, platter count is in Seagate's specs, rpm are not specified, but if they really are 2TB/platter it has to be lower than 5400rpm to only have the same performance as the old 1.33TB/platter drives. http://www.seagate.com/www-content/product-content/barracuda-fam/barracuda-new/en-us/docs/100805918d.pdf

You should, your filesystem was practically 100% allocated, 232.88 out of 232.89GiB, so only 0.01 GiB were being trimmed.

Typical cache usage, i.e., constantly filling up and emptying the cache exacerbates the large slack issue, this is supposed to improve once we get to kernel 4.14 as there are some modifications to deal with this, but until then it's a good idea to monitor this and/or do a periodic balance, not only because of the trim issues but also because in extreme cases you can run into another issue, btrfs reporting the device full when it's not because it's fully allocated and can't create any new chunks. If doing a periodic balance it should be enough to do a partial balance, it will recover most of the free allocated space but it will be much faster and cause much less wear on the SSD, e.g.: btrfs balance start -dusage=75 /mnt/cache This will only re-allocate chunks that are up to 75% unused.

I have a theory on why some users may be having this issue, if anyone wants to try and post if there was an improvement please do. Currently fstrim on btrfs is only trimming the unallocated space, this is apparently a bug but it's been like this for some time, for some users with a large slack on the filesystem this will be a very small area of the SSD leaving all unused but allocated space untrimmed, this can lead to very poor performance, so first check for slack on the filesystem, i.e., the difference between the allocated and used space, on the main page click on cache and look at the "btrfs filesystem show" section, e.g.,: Label: none uuid: cea535d2-33f9-4cf2-9ff0-0b51826d48a1 Total devices 1 FS bytes used 265.61GiB devid 1 size 476.94GiB used 427.03GiB path /dev/nvme0n1p1 In this case there's about 161GiB of slack, 476.94GiB is the total device size, 427.03GiB are allocated but only 265.61GiB are in use, since only unallocated space is trimmed, fstrim will only trim 49.9GiB (476.94-427.03) so most free space will remain untrimmed, to fix this run a full balance to reclaim all allocated but unused space, on the console type: btrfs balance start --full-balance /mnt/cache This will take some time, in the end it should look like this: Label: none uuid: cea535d2-33f9-4cf2-9ff0-0b51826d48a1 Total devices 1 FS bytes used 265.68GiB devid 1 size 476.94GiB used 266.03GiB path /dev/nvme0n1p1 Now slack space is less than 1GiB, so fstrim will work on practically all unused space, trim you pool: fstrim -v /mnt/cache And check if performance improves.

Yeah, but it should be noticeably faster, not similar, that together with the WLR dropping from 180TB to 55TB/year makes me think the older models are superior, hell, if a user does a parity check a month just that is enough to go well above the recommended 55TB/year.

That's disappointing, was expecting it to be significant faster than the old one, since it has 4 platters instead of 6.

It is pre-rc8, and he's using v6.3.5

Not for a rebuild, a rebuild doesn't care for an existing partition (well except rc8 but that is a bug), only way to test if UD is partitioning the disks correctly is to add them to the array after a new config, preferably with rc8, as it is more strict than pre-rc8.

Formatting a disk outside the array is only needed if it's going to be loaded with data and later added to the cache slot or as data disk after a new config, it's not needed (and it doesn't matter if it's formatted or not) when rebuilding an existing disk.

Parity remains in sync.

Mostly for spinners when using high fragmentable data, like VM images, usually SSDs can tolerate the high fragmentation, though it can still slowdown for heavily modified VM images or large databases, but with nodatacow you also lose checksuming.

I'd really like if someone with one of these new 8TB Seagates would post a disk speed graph to see how it compares to the old 8TB Archives.

On further reading, looks like TGMR can still be SMR , so probably shingled the same but with bigger platters, still better, wont comment on the warranty, you need to decide about that yourself.

According to Seagate those disks are not SMR, they are TGMR, they are also 2TB per platter vs 1.33TB per platter for the shingled ones, so they should be superior in every aspect.

A case with a good general airflow is enough, but I like to have a lateral case fan blowing directly on them to keep them cooler, I find that a low speed large fan, 120mm or larger is enough.

Yes.

They run pretty hot, even when idling, these controllers require some airflow on them to keep temps below 60C when in use.

You're seeing (and using) the emulated disk, only when the rebuild finishes it switches to the actual disk.

I assumed you had already removed the script, it's only needed for unRAID v5, but glad it's working now, don't forget you can't enable VT-d

Controller is loading a PATA driver, instead of AHCI, best bet it to get a different controller, LSI are recommended. 01:00.1 IDE interface [0101]: Marvell Technology Group Ltd. 88SE912x IDE Controller [1b4b:91a4] (rev 11) Subsystem: Marvell Technology Group Ltd. 88SE912x IDE Controller [1b4b:91a4] Kernel driver in use: pata_marvell Kernel modules: pata_marvell

VT-d is still enable.

If it's the Marvell issue disabling VT-d is the only fix to always work, iommu=pt doesn't always work, post your diagnostics with VT-d disable.

No, there's no clearing during when replacing an existing data disk, only when adding a new disk to the array.

Probably related to this:

If your going to use it to replace a smaller drive no, if adding to the array you just clear it using the GUI. You can change 2 at the same time if you have dual parity, with single parity just one at a time.