Marvin_Nor

Haha. pretty much. 
 
There's a lot of it coming from Ignite, and some of the firms we work with also states that 2019 is better.
Here's a link that summarizes some of the 2019 improvements.
https://blogs.technet.microsoft.com/filecab/2018/06/27/windows-server-summit-recap/
 
Of these five, I am personally mostly interested in point three.
 
Here's some good Ignite sessions too:
https://myignite.techcommunity.microsoft.com/sessions/65880
 

Haha. pretty much. 
 
There's a lot of it coming from Ignite, and some of the firms we work with also states that 2019 is better.
Here's a link that summarizes some of the 2019 improvements.
https://blogs.technet.microsoft.com/filecab/2018/06/27/windows-server-summit-recap/
 
Of these five, I am personally mostly interested in point three.
 
Here's some good Ignite sessions too:
https://myignite.techcommunity.microsoft.com/sessions/65880
 

This also introduces resiliency tiering, parity is intended for archive storage in Storage Spaces / S2D. Can cause some latency, the parity in Storage Spaces is greatly impacted by CPU speeds.
Resiliency tiering works on 2016, but it's not all that good for big workloads. Heard it's actually working wonders in 2019, but have no personal experience with it. 
Yeah, I think the only reason to pin files is in VDI environments.

In that case the Journal would be write and read cache for HDD, but write only cache for the two SSDs in Fast Tier. And it would shuffle data between slow and fast tier if necessary, while also caching the data. The benefit would be more capacity, and data would be retained on SSDs for a longer period of time due to the fast tier, but would be moved to SSDs faster due to the Journal (while moving data from slow to fast tier). So, could be a gain, if the file usage isn't consistent, but more sporadic. 
 
Really depends on usage I would say.

Ah, right, I come from a primarily S2D Environment with SSD + HDD or NVMe + SSD + HDD, where it won't ever give you the option to define a fast tier unless it's a three tiered solution, or you define costume tiers and make a vDisk based on your own tiers. So it fully commits all fast disk as cache.
Yeah, the cache you're seeing is just a dedicated space on the fast tier, as opposed to S2D where all the fast drives will be cache, again, unless you define it otherwise.
 
Personally had bad experience with standard SS, reaching 500k IOPS is no issue, but when I've put workloads on it, the latency really starts growing (used it for backup). So, switched over to S2D for everything, 1-2M IOPS and still below 1ms latency, happy with that.