SSD Speed

[FredG89]

So I'm experience a weird issue with my Cache Drive. Whenever I write to the SSD from outside the array (Computer). It writes at 110-115 MBps (Max write of my HDD)...but when I write from one part of the Cache Drive to another, I rarely get 30-40 MBps and usually it drops down to 2-10 MBps and a lot of the time it completely stops. Has anyone else had this issue? Maybe related to trim? I understand that there should be a performance hit when writing from one part of the SSD to the other has it is half-duplex....but I don't think it should be that bad, right?

 

I have:

Intel i7 4790k

8 Gigs of DDR3

12 HDD connected (some through Supermicro controller/some through SATA)

Crucial 500GB BX100 SSD

[Squid]

So I'm experience a weird issue with my Cache Drive. Whenever I write to the SSD from outside the array (Computer). It writes at 110-115 MBps (Max write of my HDD)...but when I write from one part of the Cache Drive to another, I rarely get 30-40 MBps and usually it drops down to 2-10 MBps and a lot of the time it completely stops. Has anyone else had this issue? Maybe related to trim? I understand that there should be a performance hit when writing from one part of the SSD to the other has it is half-duplex....but I don't think it should be that bad, right?

 

I have:

Intel i7 4790k

8 Gigs of DDR3

12 HDD connected (some through Supermicro controller/some through SATA)

Crucial 500GB BX100 SSD

Sounds like you're doing everything over the network.

 

In that case, going from your desktop to the cache drive you're basically going to max out the network speed.

 

Moving from one share on the cache to a different share on the cache in *theory* should also max out the network speed (or be a little slower) when the network (source and destination) are full-duplex

 

In practice however that's not always the case simply because you're relying on both NIC's to properly handle the simultaneous transfers back and forth.  Realtek NIC's in particular have an issue with being able to do full duplex at full speed.

 

There is a way to instantaneously move files from one share to another on the cache drive, but it involves enabling disk shares which brings the risk of accidentally hitting the so-called "user-share copy bug" (which IMO isn't a bug)

[FredG89]

So I'm experience a weird issue with my Cache Drive. Whenever I write to the SSD from outside the array (Computer). It writes at 110-115 MBps (Max write of my HDD)...but when I write from one part of the Cache Drive to another, I rarely get 30-40 MBps and usually it drops down to 2-10 MBps and a lot of the time it completely stops. Has anyone else had this issue? Maybe related to trim? I understand that there should be a performance hit when writing from one part of the SSD to the other has it is half-duplex....but I don't think it should be that bad, right?

 

I have:

Intel i7 4790k

8 Gigs of DDR3

12 HDD connected (some through Supermicro controller/some through SATA)

Crucial 500GB BX100 SSD

Sounds like you're doing everything over the network.

 

In that case, going from your desktop to the cache drive you're basically going to max out the network speed.

 

Moving from one share on the cache to a different share on the cache in *theory* should also max out the network speed (or be a little slower) when the network (source and destination) are full-duplex

 

In practice however that's not always the case simply because you're relying on both NIC's to properly handle the simultaneous transfers back and forth.  Realtek NIC's in particular have an issue with being able to do full duplex at full speed.

 

There is a way to instantaneously move files from one share to another on the cache drive, but it involves enabling disk shares which brings the risk of accidentally hitting the so-called "user-share copy bug" (which IMO isn't a bug)

 

So am I understanding it correctly that when I'm copying from folder to folder on my SSD through windows...It's actually coming back to my computer before moving to the other folder? When I say from one share to another on an SSD I mean moving from like /nzbget/completed >>> /Media. Which both are on the cache drive, it also seems to be affecting my dockers as Emby seems to run slower than it did on a HDD or when I first set it up on the SSD.

[Squid]

Here's the techie details of what is happening.

 

Most people expect that when you move a file from one place on a disk to another that it's going to be instantaneous because that is what they are used to from a windows environment and working with a local drive.

 

Doing moves over a network connection means that you're dealing with shares or mounts.  Moving a file over the network from one folder within a share to another folder within the same share is instantaneous.  However moving a file from one share to another share over the network means that it's a copy followed by a delete and has to transfer the file to your desktop in the process  (windows / Mac / Linux all operate the exact same way in this respect)

 

It doesn't actually matter that ultimately the source and destination are on the same disk.  The remote computer doesn't know that because it sees that they are on different network shares and automatically does the copy / delete procedure.  (The same thing also happens between windows computers

In your case, it sounds like you're moving from a folder within the app data share to your media share.  Since they are different mount points the system will copy and delete.  Even having the apps do the copy themselves will still result in the copy delete because of the differing mounts  (and this behaviour can also be replicated wlocally within windows quite easily)

 

You can jump through some hoops to avoid this behaviour but it is the safest way of doing things and is the same expected behavior amongst all operating systems

 

This is just with relation to moves.  Emby (which I don't use) is probably just creating Metadata files and if it is indeed slowing down over time them it could be related to trim.  Check out dynamic ssd trim plugin.  You can find it within community applications

 

Sent from my SM-T560NU using Tapatalk

 

 

[FredG89]

Here's the techie details of what is happening.

 

Most people expect that when you move a file from one place on a disk to another that it's going to be instantaneous because that is what they are used to from a windows environment and working with a local drive.

 

Doing moves over a network connection means that you're dealing with shares or mounts.  Moving a file over the network from one folder within a share to another folder within the same share is instantaneous.  However moving a file from one share to another share over the network means that it's a copy followed by a delete and has to transfer the file to your desktop in the process  (windows / Mac / Linux all operate the exact same way in this respect)

 

It doesn't actually matter that ultimately the source and destination are on the same disk.  The remote computer doesn't know that because it sees that they are on different network shares and automatically does the copy / delete procedure.  (The same thing also happens between windows computers

In your case, it sounds like you're moving from a folder within the app data share to your media share.  Since they are different mount points the system will copy and delete.  Even having the apps do the copy themselves will still result in the copy delete because of the differing mounts  (and this behaviour can also be replicated wlocally within windows quite easily)

 

You can jump through some hoops to avoid this behaviour but it is the safest way of doing things and is the same expected behavior amongst all operating systems

 

This is just with relation to moves.  Emby (which I don't use) is probably just creating Metadata files and if it is indeed slowing down over time them it could be related to trim.  Check out dynamic ssd trim plugin.  You can find it within community applications

 

Sent from my SM-T560NU using Tapatalk

 

That makes complete sense. I was thinking more towards maybe it was a queue depth issue or something. SMH Working in enterprise makes you think completely differently. I thought that maybe it was copying and writing to itself at the same time but I figured that it was related to a hardware issue rather than just how the systems work.

 

Thanks.

[roberth58]

If the client is win8.1 or win10 won't server side copy stop this problem as long as the source and destination are in the same share. I have found unraid to be a bit weird with SSD cache drives as far as speed. Copying to a cache only share I get 250-300MB/s (10Gb connection) but if I copy to a share with cache enabled it can drop to 60MB/s.

[Squid]

If the client is win8.1 or win10 won't server side copy stop this problem as long as the source and destination are in the same share. I have found unraid to be a bit weird with SSD cache drives as far as speed. Copying to a cache only share I get 250-300MB/s (10Gb connection) but if I copy to a share with cache enabled it can drop to 60MB/s.

If the source and destination are within the same share, then it's immediate regardless of whether done locally or on the server.

 

If the source and destination are not within the same share, then doing it locally is still a copy / delete process unless they are on the same disk, in which case you can reference both the source and destination as /mnt/diskx/share instead of /mnt/user/share