Topic: Recommendations on a PCI-E USB 3.0 card

[piran]

Wondered;-/ It comes down to how you do it,
when you do it and by what mechanism:-)
Certainly eSATA is fast but there's a cost.
Your "mirror"... that's RAID1?
We've tried big file runs - in and out - under
RAID5 and it just got impossible to use SME
for anything else ...the utils became unbearable.
Hence we drop the 8TB Win8 workstation stuff
on to a dedicated gigabit NIC hooked up to a
NAS box. Fortunately that box itself has 2 NICs
so it's available for use elsewhere (including SME).

[ghorst352]

I actually was using my server in production mode while doing the rsnapshot backup and I can tell you it was absolutely 100% unnoticeable.  The beauty of rsnapshot is its speed and being low on resources.  I always go back to rsnapshot for backups, I have tried Bacula and other progs but rsnapshot always impresses me.

[ghorst352]

Just to make clear I was running rsnapshot and backing up 5 physical servers and 2 Virtualized servers for a total of 7 servers over a gigabit network to an external eSATA hard drive while in production.   Absolutely no issues on resources, NONE.

[piran]

Noted. We use the old DAR2 contrib for exactly the same
reasonings - in particular its low use of resources and
autonomous functionality. Once stuff starts using networks
things become bearable but network throughput and so on
becomes more of an issue. At least then SME doesn't get
loaded down with what should be invisible back-office work.

[piran]

Year or two back I noticed that eSATA was very hungry
on resources... did the job but at a 'high' cost. Looks
like it's still the same. Can't see USB3 improving on it.
Maybe I'm wrong. Hope so.

[ghorst352]

To recap,

My original issue was the sluggishness of USB 2.0 for external drive backups.  I decided to investigate using USB 3.0 w/ SME Server 8.0 (Centos 5. but then it became clear that the base OS did not support USB 3.0 so then I had at least 2 options I knew that would work which would be to go with Hot swap drive bays or try out eSATA.   The read/write rates of eSATA are so fast that you are only being held back by the I/O of the harddrive.  So it doesn't even matter if I was using USB 4.0 (being funny) because the limitations come back to the physical harddrive.  I don't see any reason why anybody should not investigate using eSATA for huge file transfers and especially if your in the same predicament as I was because the OS did not support USB 3.0.  eSATA has accomplished the task at hand and then some.

[ghorst352]

I too have used the Dar2 contrib and here again I don't think I could compare the performance of rsnapshot to Dar2 or anything else.  I think we have to compare apples to apples.

[ghorst352]

I believe just from quickly looking at google, the "dd" command by default is a resource hog unless you pass parameters to toggle its usage.  I don't think you should add weight to my dd benchmark as far as resource utilization.  IMHO.

[piran]

Agreed. I get used to ignoring 'lab test' figures:-)
I always use real world transfers ...like bunches of
DVDr-sized files (4.7GB) at a time. Have fun and
good luck with your go-faster implementations!

[purvis]

hey bhay3s

If it is not too late.
Would you mind running those same test under a similar condition from a bash file and using the two command lines before your testing code and then see what kind of effects you get.
I am curious to know if it tames some of your problems.
Also do not be too surprised if it transfers more data in the same period.
I ask you to do this, because you are setup now for it and know what to look for and also you have previous results to compare the amount of data transferred in x amount of time and results for showing overload of resources.

Code: [Select]

/usr/bin/renice 19 -p $$ > /dev/null
/usr/bin/ionice -c3 -n7 -p $$ > /dev/null