I'm moving nearly 2 TB of movies to my new server (through my 750GB SSD cache).  Getting about 100MB/s average transfer speed over the entire process.  I think that's pretty good, but wanted to check with folks to see what kind of speeds they are getting.  In case I should be considering something.  1GB/s network is about 125MB/s, so with protocol overhead and such, 100MB/s (at a 20% overhead) seems ok?

 

This is what the Array Status page and the file transfer looks like with 5GB to go.

 

http://my.jetscreenshot.com/12412/20150423-zkoq-230kb

 

Comments?  Suggestions?  "just enjoy it"?

Sounds about right for an array with no parity protection. I've not followed your issues closely, so I'm assuming you are waiting to get parity running until after you populated your array with data?

Yeah, parity is running, but I keep rebooting for one reason or another and it has to start over.

Those speeds are very good.    You should get that range even with a parity drive, since you're using a cache [As long as you don't move more data than you can cache until the Mover has a chance to empty the cache].

 

 

You should get that range even with a parity drive, since you're using a cache [As long as you don't move more data than you can cache until the Mover has a chance to empty the cache].

 

Is it possible that I missed a feature of the cache drive philosophy?

You mean if I check that box (use cache drive) and I choose to copy straight to the array, the writes will be buffered in the cache drive and then (simultaneusly) copied to the share/array?

Is the mover automatically kicking in?

In my experience this will cut the cache drive performance - but I have no SSD as a cache...

 

 

While I rsynced my server to the backup rig (without parity enabled), I did not cross the 70MB/s (for big files).

According to the rsync verbose output.

 

Is it possible that I missed a feature of the cache drive philosophy?

You mean if I check that box (use cache drive) and I choose to copy straight to the array, the writes will be buffered in the cache drive and then (simultaneusly) copied to the share/array?

Is the mover automatically kicking in?

In my experience this will cut the cache drive performance - but I have no SSD as a cache...

It depends on what you mean by "copy straight to the array"!

 

If you are writing directly to a disk?? type share then you are bypassing the cache drive.   

 

If you are writing to a User share then if cache drive is enabled for that share writes of new files actually go to the cache drive and are moved to the data drives when mover runs.  Default for mover is daily at 3:40 AM but this is adjustable both for time and frequency.

Those speeds are very good.    You should get that range even with a parity drive, since you're using a cache [As long as you don't move more data than you can cache until the Mover has a chance to empty the cache].

 

Sure. In this case, more data has been transferred than the cache drive can hold, so speeds would certainly be lower towards the end with parity. But I have a hard time imagining that these volumes of data will be transferred very often. No biggie.

 

More worrying, though: If the web-UI in the screenshot is up to date, the cache drive isn't being used for the destination "movies". The amount of used space looks more like just a Docker image (around 10G). No user share write caching...

 

I'm moving nearly 2 TB of movies to my new server (through my 750GB SSD cache).  Getting about 100MB/s average transfer speed over the entire process.  I think that's pretty good, but wanted to check with folks to see what kind of speeds they are getting.  In case I should be considering something.  1GB/s network is about 125MB/s, so with protocol overhead and such, 100MB/s (at a 20% overhead) seems ok?

 

This is what the Array Status page and the file transfer looks like with 5GB to go.

 

http://my.jetscreenshot.com/12412/20150423-zkoq-230kb

 

Comments?  Suggestions?  "just enjoy it"?

 

I typically use FTP for transfers, so I can't comment on the overhead and transfer rates for SMB. Still, you might be slightly limited by the speeds of the HDD you are reading from and/or the ones you are writing to, but it isn't a life-changing difference in speed. 

 

From a network perspective it's pretty good, with gigabit networking you can't go much faster so I'd say "just enjoy it" if it hadn't been for two things...

 

1. Speed tests without a proper parity are not very interesting to me, that's only good for the initial transfer and not real-life use.

2. The cache drive don't seem to be in use for the transfer. If the web UI in the screenshot was up to date, you should probably double-check your user share cache drive settings.

 

 

It depends on what you mean by "copy straight to the array"!

 

If you are writing directly to a disk?? type share then you are bypassing the cache drive.   

 

If you are writing to a User share then if cache drive is enabled for that share writes of new files actually go to the cache drive and are moved to the data drives when mover runs.  Default for mover is daily at 3:40 AM but this is adjustable both for time and frequency.

 

I meant copying to the user share.

But it seems my world is still intact. Mover is not running automatically and simultaneusly while data is copied to the cache.

 

100MB/s is pretty nice when written straight to the parity protected storage.

I usually observe 40MB/s in my setup, but sometimes I also see 100MB/s - file size ~10GB...strange.

You should get that range even with a parity drive, since you're using a cache [As long as you don't move more data than you can cache until the Mover has a chance to empty the cache].

 

Is it possible that I missed a feature of the cache drive philosophy?

You mean if I check that box (use cache drive) and I choose to copy straight to the array, the writes will be buffered in the cache drive and then (simultaneusly) copied to the share/array?

Is the mover automatically kicking in?

In my experience this will cut the cache drive performance - but I have no SSD as a cache...

 

 

While I rsynced my server to the backup rig (without parity enabled), I did not cross the 70MB/s (for big files).

According to the rsync verbose output.

 

Not exactly. Mover is a script that cron runs at specified time intervals. You can also manually invoke mover. But mover is not simultaneous, and does not kick in automatically when a transfer occurs.

Also based on how mover works by using rsync I'm not sure that this can really be achieved since the risk of partial files (files still being writen to the cache) being copied is too high.

 

Yes, I know and use mover (manually).

That's why I was wondering about this statement.

 

You should get that range even with a parity drive, since you're using a cache [As long as you don't move more data than you can cache until the Mover has a chance to empty the cache].

 

I thought I missed some mover feature...

 

 

Yes, I know and use mover (manually).

That's why I was wondering about this statement.

 

You should get that range even with a parity drive, since you're using a cache [As long as you don't move more data than you can cache until the Mover has a chance to empty the cache].

 

I thought I missed some mover feature...

 

No biggie, I think that feature was requested, but as I said earlier knowing that mover uses rsync it seems like there is risk for copying of partially completed files, resulting in "corruption."

 

I like the idea if there is a way to make it work. 

The mover ignores open files.