This message was deleted.
# microsoft-fslogix
s
This message was deleted.
j
@Dave Brett has had great experience with that as well.
r
It's super nice man. I did the trial it's awesome stuff.
I like how it will track changes and merge them
n
I've seen @James Kindon post about it and @Leee Jeffries mention it, so it saved me the hassle of going the usual robocopy route.
r
I have a blog I wrote on it. But my trial expired and I need to buy it to do finish it. It saved me some time as well.
j
ping Alex @Ray Davis.... he is awesome and will give you a trial key. Best product around for data replication
r
Sweet man. I'll look up Alex. Thanks James.
n
Yeah, I may wind up having to buy it out of pocket since the trial will end before our 2nd migration.
Being $30m over budget has made the paper pushers grumpy.
r
It's worth every penny. if my company doesn't buy it. I will.
Yes I understand that
I meant to ask, is it going on the isilon?
n
Nope, the storage team pulled a 5TB LUN out of their rear end and created a new volume on the same single host. I have no timeframe on the Isilon stuff, but I imagine we won't see it for a few months at the very least.
r
Oh man. Amazing how space can appear when needed lol.
Magic
n
That's exactly what I said to them when they told me they were adding it, haha.
๐Ÿ‘ 1
s
Forgive me, but can i get a use case. Im use to veeam and replicated luns to DR for our fslogix repo. Also looking into cloud cache. Where would this benefit me? thanks
j
live realtime block level replication to another SMB share - mounted or not, block level goodness controlled at Windows Level. Cloud Cache will be the bomb when it has its performance issues fixed, that will then become the defacto standard i would think
l
@James Kindon I agree but we need to see some proper guidance on architecting non-persistent solution with cloud cache. I still haven't had the time to sit down and map it out.
j
once it's stable and fast without needing SSD/Flash everywhere to negate logon/logoff impacts, we will be able to get it out there more - we know the technology works beautifully, its just the performance impacts at the moment - almost there ๐Ÿ™‚
l
I hear you there. My thoughts were more along the lines of estimating the cache size and what that looks like on scale.
j
You and me both - looking forward to the first customer that pushes some serious density onto server vdas ๐Ÿค˜๐Ÿค˜
d
when its available and stable - i would image that will be us mate ๐Ÿ™‚
l
Looking forward to it, I have a presso slot at the next CUGC for storage types for FSL as we have those discussions alot on here.
n
Feel free to send it to Microsoft when you're done...
๐Ÿ‘ 2
s
Where does the performance issue stem from cloud cache? I thought that only writes were syncing to the cloud after the initial upload. Is there some type of logon penalty?
l
Yes that's true but how much data did you write? How long does that take to merge?
s
So is the performance hit only at log off then? Or are you saying that the filesystem is waiting to merge the writes on the fly thys slowing down the system. If its only log off then if your lucky or unlucky enough to use Citrix WEM, fast log off would help.
l
It's not about a performance hit so much. It's more about what happens at scale. On a non-persistent machine there is only so much write space. How do you size that right space at scale? Fast Logoff is a good example. Is that a good idea? What us you log straight back in and your VHD is locked by the merge operation. Its weeding out all this to answer the questions.
j
I am on the blatant performance impact bandwagon - unless you have a crazily fast backend, I've seen random long delays on both logon and logoff as both the cache builds and is flushed. Its completely inconsistent and I couldn't rarely get the same result twice - dignified by Microsoft with a fix on the way - then it will be onto the fun stuff above which Mr Jeffries is rightly focusing on
๐Ÿ‘ 1
โคด๏ธ 1