<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: NFS, FTP or SSH file transfer in Operating System - Linux</title>
    <link>https://community.hpe.com/t5/operating-system-linux/nfs-ftp-or-ssh-file-transfer/m-p/5290399#M81391</link>
    <description>&lt;P&gt;Another option to look at is "netcat" I find it moves data rather quickly&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;copy&amp;nbsp;data from machine A to machine B&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;on machine A&lt;/P&gt;&lt;P&gt;# cd {target directory}&lt;/P&gt;&lt;P&gt;# tar -cf - . | nc -w 3 -l -p 5432&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;on machine B&lt;/P&gt;&lt;P&gt;# nc -w 5 a.example.com 5432 | tar -xvf -&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The command sets up a tar process on machine A that waits for a tcp connection on port 5432. When a client (machine B) connects, tar simply sends all the data through that tcp port. No temporary files are required.&lt;/P&gt;&lt;P&gt;On machine B, another tar process reads from the network via netcat, writing the data to the disks as it streams over the network&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;NOTE: on some distros netcat is called using "nc" instead of "netcat"&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Wed, 03 Aug 2011 15:52:34 GMT</pubDate>
    <dc:creator>Jimmy Vance</dc:creator>
    <dc:date>2011-08-03T15:52:34Z</dc:date>
    <item>
      <title>NFS, FTP or SSH file transfer</title>
      <link>https://community.hpe.com/t5/operating-system-linux/nfs-ftp-or-ssh-file-transfer/m-p/4799721#M81388</link>
      <description>hi&lt;BR /&gt;&lt;BR /&gt;Which is the quickest file transfer via NFS, FTP or SSH in 100MB LAN?</description>
      <pubDate>Fri, 17 Jun 2011 21:09:07 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/nfs-ftp-or-ssh-file-transfer/m-p/4799721#M81388</guid>
      <dc:creator>'chris'</dc:creator>
      <dc:date>2011-06-17T21:09:07Z</dc:date>
    </item>
    <item>
      <title>Re: NFS, FTP or SSH file transfer</title>
      <link>https://community.hpe.com/t5/operating-system-linux/nfs-ftp-or-ssh-file-transfer/m-p/4799722#M81389</link>
      <description>&lt;!--!*#--&gt;&amp;gt; [...] NFS, FTP or SSH [...]&lt;BR /&gt;&lt;BR /&gt;Or "rcp", or "rsh"/"remsh", or "rsync", or&lt;BR /&gt;Kermit, or ...&lt;BR /&gt;&lt;BR /&gt;It probably depends on many missing bits of&lt;BR /&gt;information (software, hardware, ...).  I'd&lt;BR /&gt;expect free advice obtained here to be less&lt;BR /&gt;reliable than data obtained from some simple&lt;BR /&gt;tests on representative files.&lt;BR /&gt;&lt;BR /&gt;If your CPUs are faster than your network,&lt;BR /&gt;then compress+transfer+decompress may be&lt;BR /&gt;faster than a simple transfer.  A "tar" (or&lt;BR /&gt;cpio, ...) pipeline (with or without&lt;BR /&gt;compression) can preserve file ownership&lt;BR /&gt;and/or permissions.  Some programs deal&lt;BR /&gt;better with symbolic links, sparse files, and&lt;BR /&gt;so on than others.&lt;BR /&gt;&lt;BR /&gt;Everything's complicated.  Accurate answers&lt;BR /&gt;to terse questions, especially so.</description>
      <pubDate>Fri, 17 Jun 2011 22:08:47 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/nfs-ftp-or-ssh-file-transfer/m-p/4799722#M81389</guid>
      <dc:creator>Steven Schweda</dc:creator>
      <dc:date>2011-06-17T22:08:47Z</dc:date>
    </item>
    <item>
      <title>Re: NFS, FTP or SSH file transfer</title>
      <link>https://community.hpe.com/t5/operating-system-linux/nfs-ftp-or-ssh-file-transfer/m-p/5290339#M81390</link>
      <description>&lt;P&gt;SSH is encrypted traffic.&amp;nbsp; It may be slowest because of the extra overhead that happens during encryption/decryption between the local and remote hosts (I'm thinking "SFTP" file transfers here).&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I'm no famiiliar with NFS at all, and FTP transmits password on clear view.&amp;nbsp; I'd have to say, FTP has less overhead and may still be fastest way to transfer files remotely.&lt;/P&gt;</description>
      <pubDate>Wed, 03 Aug 2011 14:42:56 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/nfs-ftp-or-ssh-file-transfer/m-p/5290339#M81390</guid>
      <dc:creator>eanebab</dc:creator>
      <dc:date>2011-08-03T14:42:56Z</dc:date>
    </item>
    <item>
      <title>Re: NFS, FTP or SSH file transfer</title>
      <link>https://community.hpe.com/t5/operating-system-linux/nfs-ftp-or-ssh-file-transfer/m-p/5290399#M81391</link>
      <description>&lt;P&gt;Another option to look at is "netcat" I find it moves data rather quickly&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;copy&amp;nbsp;data from machine A to machine B&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;on machine A&lt;/P&gt;&lt;P&gt;# cd {target directory}&lt;/P&gt;&lt;P&gt;# tar -cf - . | nc -w 3 -l -p 5432&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;on machine B&lt;/P&gt;&lt;P&gt;# nc -w 5 a.example.com 5432 | tar -xvf -&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The command sets up a tar process on machine A that waits for a tcp connection on port 5432. When a client (machine B) connects, tar simply sends all the data through that tcp port. No temporary files are required.&lt;/P&gt;&lt;P&gt;On machine B, another tar process reads from the network via netcat, writing the data to the disks as it streams over the network&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;NOTE: on some distros netcat is called using "nc" instead of "netcat"&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 03 Aug 2011 15:52:34 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/nfs-ftp-or-ssh-file-transfer/m-p/5290399#M81391</guid>
      <dc:creator>Jimmy Vance</dc:creator>
      <dc:date>2011-08-03T15:52:34Z</dc:date>
    </item>
  </channel>
</rss>

